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SECTION  1 
INTRODUCTION 


1.1  PURPOSE 

This  document  specifies  the  program  performance  requirements  for  the  data 
processor  software  component  of  an  Advanced  Integrated  Display  System  (AIDS). 
The  AIDS  described  herein  supports  the  Airborne  Early  Warning  (AEW)  and  Anti¬ 
submarine  Warfare  (ASW)  missions  of  the  proposed  V/STOL  Type  A  aircraft.  This 
Program  Performance  Specification  (PPS)  is  intended  as  part  of  the  require¬ 
ments  specification  which  will  be  used  by  the  Navy  to  procure  V/STOL  Type  A  pro¬ 
totypes. 

This  specification  is  prepared  In  accordance  with  the  Instructions  in  "Tac¬ 
tical  Digital  Systems  Documentation  Standard^'  (SECNAV  74).  Section  1  briefly 
describes  AIDS.  Section  2  of  a  PPS  normally  lists  the  applicable  documents. 
In  this  PPS,  references  are  listed  In  a  bibliography;  Section  2  contains  only 
a  reference  to  the  bibliography.  Section  3  defines  the  functional  and  perform¬ 
ance  requirements  of  the  AIDS  software.  Section  4  describes  the  techniques  to 
be  used  to  ensure  the  quality  of  the  AIDS  software.  Appendix  A  contains  a  glos¬ 
sary  of  AIDS  acronyms.  Appendix  B  contains  a  specification  of  the  crew  control 
Inputs.^-  •  - 

^  1.2  MISSION 

The  AEW  and  ASW  missions  for  the  V/STOL  Type  A  aircraft  are  described  In 
the  "Request  for  Quotation  for  Development  of  V/STOL  Type  A  Weapon  System" 
(NAVAIR  77).  Briefly,  the  AEW  aircraft  Is  responsible  for  monitoring  the  tac¬ 
tical  environment,  sharing  tactical  Intelligence  with  other  platforms,  and 
vectoring  Intercepters  to  targets.  The  ASW  aircraft  Is  responsible  for  locating 
and  destroying  hostile  submarines. 

1.3  SCOPE 

1.3.1  Identification 

The  AIDS  processing  Is  distributed  among  AIDS  data  processors  and  the  AIDS 
microprocessors.  The  terms  "software"  and  "firmware"  are  used  In  this  specifi¬ 
cation  to  distinguish  between  programs  which  run  In  the  data  processor  (software) 
and  programs  which  run  In  the  microprocessor  (firmware).  This  document  speci¬ 
fies  only  the  AIDS  software.  This  software  comprises  the  Operational  Display 
Software  (ODS),  the  Data  Processor  ICS  Software  (DPICS),  the  Graphic  Real-Time 
Application  Display  Support  Software  (GRADS) ,  the  AIDS  Operating  System  (AOS) , 
and  the  Standard  Executive  (SDEX/M)  for  the  AM/AYK-14. 

1.3.2  Functional  Summary 

AIDS  controls  and  processes  all  the  Information  flow  between  the  aircraft 
crew  and  the  aircraft  systems.  This  Information  Includes  both  aircraft  flight 
information  and  mission  Information.  AIDS  provides  four  modes  of  Information 
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exchange.  To  the  crew,  information  Is  provided  In  a  visual  mode  through  displays 
and  In  an  audio  mode  through  voice  synthesis;  from  the  crew,  Information  is 
accepted  In  a  tactile  mode  through  control  panels  and  In  an  audio  mode  through 
voice  recognition.  To  provide  this  Information  flow  reliably  and  In  real-time, 
the  AIDS  software  performs  the  following  functions: 

o  Initialization  of  the  avionics  systems  with  the  specific  mission  and 
flight  plan  data. 

o  Input  of  flight  control  and  mission  data  from  the  "External  Avionics  Sub¬ 
systems."  These  subsystems  comprise  all  the  avionics  subsystems  In  the  aircraft 
except  AIDS. 

o  Conversion  of  Input  data  Into  appropriate  dynamic  display  formats  and  syn¬ 
thesized  voice  messages. 

o  Acceptance  of  both  tactile  and  voice  commands  from  the  crew  and  routing 
each  command  to  the  appropriate  destination,  either  Inside  or  outside  of  AIDS. 

o  Reconfiguration  of  AIDS  In  response  to  both  mission  mode  changes  and 
hardware  failures. 

The  AIDS  software  Is  partitioned  Into  a  set  of  Information  processing  and 
display  subsystems  and  a  set  of  common  support  procedures.  The  Information 
subsystems  are  the  flight  data  display  subsystem,  the  equipment  monitoring 
subsystems,  the  communication  data  display  subsystem,  the  AEW  display  subsys¬ 
tem,  and  the  ASW  display  subsystem.  The  collection  of  all  these  Information 
display  subsystems  Is  known  as  the  Operational  Display  Software  (ODS). 

Examples  of  the  support  procedures  are  the  kernel  operating  system,  the  dis¬ 
play  support  procedures,  the  tactile  command  Input  procedures,  and  the  system 
Initialization  procedures.  The  collection  of  all  the  support  procedures  Is 
known  as  the  Operational  Support  Software  (OSS).  Within  the  OSS,  the  kernel 
operating  system  Is  the  Standard  Executive  (SDEX/M)  for  the  AN/AYK-14;  the  AIDS- 
speclflc  operating  system  is  the  AIDS  Operating  System  (AOS);  the  display  support 
procedures  are  the  Graphic  Real-Time  Application  Display  Support  (GRADS)  run¬ 
time  procedures,  and  the  tactile  command  input  procedures  are  the  Data  Processor 
Integrated  Control  Set  (DPICS)  software. 

This  docuount  is  the  highest-level  specification  of  the  AIDS  software.  The 
detailed  requirements  for  each  of  the  above  AIDS  software  components  are  not 
described  herein.  For  example,  the  details  of  the  format  symbology  appearance 
and  placement  and  of  the  crew  commands  are  not  described.  The  detailed  func¬ 
tional  requirements  will  be  Included  In  Program  Performance  Specifications  for 
the  ODS,  OSS,  DPICS,  and  GRADS. 
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SECTION  2 


APPLICABLE  DOCUMENTS 


2.1  APPLICABLE  DOCUMENTS 

The  applicable  documents  are  listed  in  the  bibliography. 
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SECTION  3 

TACTICAL  DIGITAL  SYSTEM  REQUIREMENTS 


3.1  INTRODUCTION 

This  section  describes  In  detail  the  AIDS  software  functional  requirements. 

Section  3.2  describes  the  AIDS  architecture  and  lists  the  AIDS  peripherals  and 
Interfacing  programs.  Section  3.3  contains  the  functional  description.  Sec¬ 
tions  3.3.1  through  3.3.3  describe  the  hardware  and  the  hardware  Interfaces. 

Section  3.3.4  describes  the  software  Interfaces.  Section  3.3.5  Introduces  and 
briefly  describes  the  19  functions  which  constitute  the  AIDS  software.  Sec¬ 
tions  3.4.1  through  3.4.19  describe  In  detail  the  requirements  of  each  func¬ 
tion.  Section  3.5  lists  the  adaptation  parameters  of  the  AIDS  software;  these 
parameters  Include  the  throughput  and  memory  requirements  of  the  software. 

3.2  SYSTEM  DESCRIPTION 

This  subsection  describes  the  tactical  system  In  which  the  AIDS  software 
executes.  Section  3.2.1  briefly  describes  the  hardware  system.  Section  3.2.2 
lists  all  the  AIDS  peripherals,  and  Section  3.2.3  lists  all  the  programs  with 
which  the  AIDS  software  Interfaces. 

3.2.1  General  Description  *" 

t 

The  AEV  and  ASW  V/STOL  Type  A  aircraft  avionics  are  distributed  among  several 
subsystems,  one  of  which  Is  AIDS.  The  other  subsystems  are  the  Joint  Tactical 
Information  Distribution  System  (JTIDS),  Communication  System  (COMM),  Navigation 
subsystem  (NAV),  the  Universal  Locator-Airborne  Integrated  Data  System  (ULAIDS), 
the  Solid-State  Electrical  System  (SOSTEL),  the  Integrated  Engine  Instrumen¬ 
tation  System  (lEIS),  the  ASW  system,  and  the  AEW  system.  These  subsystems  com¬ 
municate  with  each  other  using  a  redundant  digital  bus  which  conforms  to  MIL- 
STD-1553.  AIDS  Is  responsible  for  Interfacing  these  systems  with  the  crew. 

The  AIDS  software  specified  In  this  specification,  as  well  as  the  other 
V/STOL  avionics,  will  exist  In  two  versions,  one  supporting  the  AEW  mission 
and  one  supporting  the  ASW  mission.  A  large  portion  of  these  avionics  will 
be  common  to  both  versions.  This  portion  is  known  as  the  core  avionics.  In 
general,  the  core  avionics  support  the  pilot,  whereas  the  noncore  avionics 
support  the  particular  mission. 

AIDS  Is  modular  In  terms  of  both  hardware  and  software.  A  common  set  of 
AIDS  modules  will  be  used  to  construct  both  the  AEW  and  ASW  versions.  In  terms 
of  the  AIDS  software,  the  AEW  and  the  ASW  display  subsystems  shall  encapsulate 
the  differences  between  the  two  versions.  The  other  AIDS  software  modules 
shall  be  common  to  both  versions.  This  same  partitioning  applies  to  the  AIDS 
hardware,  described  below. 

AIDS  provides  six  displays  for  the  pilot;  Head-Up  Display  (HUD),  Helmet  v 

Mounted  Display  (HMD),  Vertical  Situation  Display  (VSD),  Horizontal  Situation  ) 

Display  (HSD),  Left  Status  Advisory  Display  (LSAD),  and  Right  Status  Advisory 
Display  (RSAD).  The  HUD,  HMD,  and  VSD  present  flight  data;  the  HSD  displays 
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^  tactical  data  superimposed  on  a  moving  map  display;  the  two  SADs  present 
engine,  communication,  and  aircraft  status  information.  The  HUD,  HMD,  VSD, 
and  HSD  are  also  capable  of  displaying  sensor-generated  video  (e.g. ,  Low-Light- 
Level  TV  (LLLTV)  and  Forward-Looking  Infrared  (FLIR)). 

For  the  ASW  mission,  AIDS  provides  three  displays  for  each  of  the  two  mis¬ 
sion  officers;  the  Sensor  Officer  (SENSO)  and  the  Tactical  Officer  (TACCO).  The 
displays  are  a  Tactical  Display  <TD),  an  Auxiliary  Display  Unit  (ADU),  and  a 
Status  Advisory  Display  (SAD).  The  11)  presents  geographically  oriented  sensor 
and  target  positions,  the  ADU  displays  acoustic  information,  and  the  SAD  aug¬ 
ments  both  the  TD  and  ADU  with  alphanumeric  annotation. 

For  the  AEU  mission,  AIDS  provides  two  displays  for  each  of  the  three  mis¬ 
sions  officers,  a  TD  and  an  SAD.  The  AEW  officers  are  the  Combat  Information 
Control  Officer  (CICO)  and  two  Air  Control  Officers  (ACOl  and  AC02).  The  TD 
displays  the  geographically  oriented  tactical  environment  and  the  SAD  provides 
alphanumeric  annotation  of  the  TD  symbology. 

In  both  versions,  the  pilot  station  and  each  mission  officer  station  Include 
an  Integrated  Control  Panel  (ICP).  The  TCP  contains  both  fixed  and  variable 
function  switches  as  well  as  a  force  stick.  The  force  stick  provides  each  crew¬ 
member  with  an  analog  input  device.  In  addition  to  an  ICP,  the  pilot  is  provided 
with  a  Mode  Control  Panel  (MCP).  The  MCP  contains  fixed  switches  with  which  the 
pilot  specifies  the  current  mission  mod&.  The  ICPs  and  the  MCP  support  the  tactile 
{  crew  input  mode.  A  signal  voice  recognition  system  provides  a  voice  input  mode. 

The  allocation  of  this  system  to  a  single  crewmember  is  a  function  of  mission 
mode. 


The  fourth  communication  mode,  voice  output,  is  provided  by  a  single  voice 
synthesis  system.  Voice  synthesis  is  used  to  alert  the  crew  to  warning  and 
caution  situations  and  to  output  system  parameters  during  information-intensive 
mission  segments.  For  example,  altitude  and  rate  of  descent  are  periodically 
output  fed  during  landing. 


In  addition  to  the  tactile  and  voice  input  modes,  which  are  used  during  the 
mission,  AIDS  provides  a  mission  data  input  device  used  during  system  Initializa¬ 
tion.  This  device  is  the  Briefing  Information  Entry  Device  (BIED).  The  BIED  is 
a  cassette  tape  reader  into  which  the  pilot  inserts  a  cassette  tape  on  which  the 
specific  mission  description  has  been  recorded. 

AIDS  is  a  distributed  system,  with  processing  distributed  among  AIDS  data 
processors  and  AIDS  microprocessors.  Currently,  the  AIDS  data  processor  is  the 
AN/AYK-14  (GE791,  CDC77)  and  the  AIDS  microprocessor  is  the  Texas  Instmments 
SBP  9900  (GE79n,  TI  76).  It  is  anticipated  that  over  the  multiyear  V/STOL 
development  period,  new  processors  may  replace  the  AN/AYK-14  and  the  SBP 
9900.  Consequently,  in  this  specification  the  terms  "data  processor”  and 
"microprocessor”  are  used  Instead  of  the  actual  computer  names.  Only  when 
computer-dependent  processing  is  described  are  the  names  "AN/AYK-14”  and 
"SBP  9900”  used. 

Each  AIDS  hardware  component  exists  either  as  a  separate  physical  unit  in  the 
cockpit  or  as  a  component  in  the  AIDS  Modular  Integrated  Display  Electronics 
Rack  (MIDER).  The  displays,  ICS,  BIED,  voice  recognition,  and  voice  synthesis 
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modules  are  cockpit  units;  the  remainder  of  the  hardware  resides  in  a  MIOER. 
The  ASW  system  requires  three  MIDERs;  the  AEW  system  requires  two  MIDERs. 

Each  MIDER  contains  one  data  processor.  The  other  components  of  a  MIDER  are 
listed  below  In  Section  3.2.2. 1. 

All  the  AIDS  hardware  components  are  Interconnected  using  buses.  AIDS  uses 
three  low-bandwidth  (~1  MHz)  digital  buses  and  one  high-bandwldth  (15  MHz)  video 
bus.  The  digital  bus  which  Interconnects  MIDER  components  Is  known  as  the  MIDER 
bus  (Mbus).  The  digital  bus  connecting  the  AIDS  cockpit  hardware  and  the  MIDERs 
is  known  as  the  Internal  bus  (Ibus).  The  digital  bus  connecting  AIDS  to  external 
avionics  subsystems  Is  known  as  the  external  bus  (Xbus).  The  video  bus  con¬ 
necting  external  video  sources  and  the  displays  to  the  MIDERs  is  known  as  the 
video  bus  (Vbus). 

Figures  3-1  and  3-2  Illustrate  the  hardware  and  Interconnections  of  the 
AIDS  for  ASW  and  AEW,  respectively.  To  complete  the  description  of  the  en¬ 
vironment  In  which  the  AIDS  software  operates,  the  AIDS  support  must  be 
mentioned. 

AIDS  requires  a  substantial  set  of  program  generation  support  software. 
This  software  Includes  the  AIDS  Display  Formatter,  the  AIDS  Command  Formatter, 
and  the  AIDS  Equipment  Formatter.  These  formatters  execute  In  the  program 
generation  system  off-line  to  AIDS  operational  software  execution.  The  for¬ 
matters  translate  descriptions  of  displays,  ICS  Interactions  and  aircraft  equip¬ 
ment  Into  tables  which  are  Included  In  the  operational  software. 

3.2.2  Peripheral  Equipment  Identification 

The  AIDS  peripheral  equipment  may  be  divided  Into  four  categories:  the  peri¬ 
pheral  equipment  connected  to  the  Mbus,  the  peripheral  equipment  connected  to 
Ibus,  the  peripheral  equipment  connected  to  the  Xbus,  and  the  peripheral  equip¬ 
ment  connected  to  the  Vbus.  The  peripheral  equipment  Is  listed  below  according 
to  these  categories.  Detailed  descriptions  of  the  equipment  and  the  AIDS  Inter¬ 
faces  are  contained  In  Sections  3.3.1  through  3.3.3. 

3.2.2. 1  MIDER  Bus  Peripheral  Equipment 

Ibus  Controllers 

Xbus  Remote  Terminal 

Mass  Memory  System 

Raster  Symbol  Generators 

Scan  Converters 

Signal  Processors 


) 
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Raster  SymMt  Gantrator  xbus  RT 

Oau  Procissor  Ibus  BC 

Mass  Mtmory  Vbus  RT 

Rtiftsh  Memory  SP 

Scan  Converter 


Xbus  Terminal 
Ibus  Controllers 
Vbus  Remote  Terminal 
Signal  Processor 


FIGURE  3-1  -  AIDS  ASV  system  configuration 
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SC  Sc«n  Convtriir 

Xbus  RT  Xbus  Tfrmlnil 

ttus  1C  Ibus  Contralltrs 

Vbus  RT  Rimolt  Tarminii 

Tac  MM  Tacticii  Mm  Mamory 


FIGURE  3-2  -  AIDS  AEW  system 
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3. 2. 2. 2  Internal  Bus  Peripheral  Equipment 
Head-Up  Display  (HUD) 

Multifunction  Displays  (MFD) 

Helmet  Mounted  Display  (HMD) 

Status  Advisory  Displays  (SAD) 

Tactical  Displays  (TD) 

Auxiliary  Display  Units  (ADU) 

Integrated  Control  Panels  (ICF) 

Mode  Control  Panel  (MCP) 

Briefing  Information  Entry  Device  (BIED) 

Voice  Recognition  System 
Voice  Synthesis  System 

Modular  Integrated  Display  Electronic  Racks  (MIDER) 

3. 2. 2. 3  External  Bus  Avionics 
Navigation  System  (NAV) 

Joint  Tactical  Information  Distribution  System  (JTIDS) 
Communications  System  (COMM) 

Universal  Locator-Airborne  Integrated  Data  System  (ULAIDS) 
Solid-State  Electrical  System  (SOSTEL) 

Integrated  Engine  Information  System  (lEIS) 

AEW  System 
ASU  System 

3. 2. 2. 4  Video  Bus  Peripheral  Equipment 
Video  Sensors  (TBD) 

Scan  Converters 
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Head-Up  Display 
Multifunction  Displays 
Helmet  Mounted  Display 
Tactical  Display 
Auxiliary  Display  Units 
3.2.3  Interface  Identification 


The  AIDS  software  Interfaces  may  be  categorized  into  three  groups:  a)  between  AIDS 
software  and  an  AIDS  firmware  program,  b)  between  AIDS  software  and  an  External 
Avionics  Subsystem,  and  c)  between  AIDS  software  and  an  AIDS  program  generation 
program.  The  Interfaces  are  listed  below  In  these  three  categories.  Descrip¬ 
tions  of  the  Interfacing  programs  and  the  corresponding  Interfaces  are  provided 
in  Section  3.3.4. 


3. 2. 3.1  AIDS  Firmware  Interfaces 

The  AIDS  software  has  Interfaces  with  the  following  AIDS  firmware: 
Mbus  Controller  Firmware 
I bus  Controller  Firmware 
Xbus  Remote  Terminal  Firmware 


3 


4 

.#■ 

3 


Mass  Memory  Firmware 

Raster  Symbol  Generator  Firmware 

Scan  Converter  Firmware 


Signal  Processor  Firmware 

Microprocessor  Integrated  Control  Set  Controller  (MFICS)  Firmware 

Briefing  Information  Entry  Device  Firmware 

Voice  Recognizer  Firmware 

Voice  Synthesizer  Firmware 

Multifunction  Display  Firmware 

Helmet  Mounted  Display  Firmware 
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^  Status  Advisory  Display  Firmware 

Head-Up  Display  Firmware 

3. 2. 3. 2  External  Avionics  Subsystems  Interfaces 

The  AIDS  software  has  Interfaces  with  the  following 
External  Avionics  Subsystems  (EAS) : 

Navigation  System  (NAV) 

Joint  Tactical  Information  Distribution  System  (JTIDS) 

Communications  System  (COMM) 

Universal  Locator-Airborne  Integrated  Data  System  (ULAIDS) 

Solid-State  Electrical  System  (SOSTEL) 

Integrated  Engine  Information  System  (lEIS) 

AEW  System 
ASU  System 

.3. 2. 3. 3  Program  Generation  Interfaces  - 

The  following  are  the  off-line  Interfaces  between  program  generation  pro¬ 
grams  and  AIDS  software  programs. 

AIDS  Command  Formatter/Data  Processor  Integrated  Control  Set  Software 
AIDS  Display  Format ter/ AIDS  Operational  Display  Software 
AIDS  Equipment  Formatter/AIDS  Operational  Display  Software 
3.3  FUNCTIONAL  DESCRIPTION 

This  section  contains  a  detailed  description  of  the  AIDS  software  functions. 
The  description  Is  presented  In  the  following  five  subsections.  Section  3.3.1 
describes  the  functional  characteristics  of  the  AIDS  hardware  modules.  Section 

3.3.2  tabulates  the  Input/output  requirements  of  the  AIDS  data  processor.  Sec¬ 
tion  3.3.3,  which,  according  to  SECNAVINST  3560.1,  should  contain  block  diagrams 
of  the  AIDS  hardware  system,  references  Section  3.2.1,  which  does  contain  these 
diagrams.  Section  3.3.4  describes  the  functional  characteristics  of  the  AIDS 
software  Interfaces.  Section  3.3.5  Introduces  the  19  ftmctlonal  modules  of  the 
AIDS  software. 


3.3.1  Equipment  Description 

k  This  section  provides  a  summary  description  of  the  AIDS  hardware  modules, 
block  diagrams  depicting  the  interconnections  of  these  modules  are  presented  in 
Section  3.2.1.  For  detailed  descriptions  of  these  modules,  refer  to  the  appli¬ 
cable  specification  listed  In  the  bibliography. 
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3. 3. 1.1  Data  Processor  (AN/AYK-14) 

Within  the  AIDS  configuration,  each  MIDER  contains  an  AN/AYK-14  minicom¬ 
puter,  the  Navy's  standard  airborne  computer  (GDC  72).  Its  general  character¬ 
istics  Include  a  16-blt  word  length,  16  general-purpose  registers,  fixed  and 
floating  point  arithmetic,  and  core  and  semiconductor  type  memory.  The  con¬ 
figuration  selected  for  the  AIDS  data  processor  Includes  128K  words  of  core 
memory,  with  a  900-nanosecond  cycle  time,  an  Extended  Arithmetic  Unit  (EAU),  a 
Discrete  Interface  Module  (DIM),  and  a  Bus  Extender  Module  (BEM). 

The  AN/AYK-14  Includes  a  memory  mapping  capability  which  obviates  the  need 
for  program  or  data  storage  to  be  continuous.  System  Integrity  Is  Increased 
through  the  designation  of  specific  user  page  access  privileges  (l.e.,  read, 
write,  and  execute  protect)  as  well  as  the  designation  of  only  those  specific 
pages  actively  used  by  a  given  task. 

During  the  AIDS  system  development  period,  a  Computer  Control  Unit  (CCU) 
will  be  attached  to  the  AN/AYK-14.  The  CCU  consists  of  an  alphanumeric  Cathode 
Ray  Tube  (CRT)  display  and  a  magnetic  tape  drive.  Interfacing  with  the  AN/AYK-14 
through  its  support  equipment  channel,  the  CCU  provides  debugging  and  program 
execution/monitoring  capabilities.  Interactions  with  the  AN/AYK-14  (via  the 
CCU  terminal)  Include:  setting  of  program  breakpoints  and  traps,  monitoring 
and  display  of  diagnostics,  and  selectively  reading  and  writing  the  contents 
of  memory  and  programmable  registers.  Initial  program  loading  of  the  AN/AYK-14 
Is  provided  by  the  CCU  tape  drive  unit. 

3.3. 1.2  MIDER  Bus  (Mbus) 

Each  module  In  a  MIDER  Is  Interconnected  to  a  16-blt  parallel  bus  known 
as  the  Mbus,  Each  attached  module.  Including  the  data  processor  AN/AYK-14, 
Interfaces  to  the  bus  through  a  16K-work,  dual-port  memory  using  two  Interrupt 
lines.  The  AN/AYK-14 's  bus  Interface  Interrupt  handling  Is  provided  by  the 
aforementioned  DIM  and  the  dual-port  memory  access  Is  provided  by  the  BEM.  The 
bus  controller  Is  an  AIDS  microcomputer  with  Interrupt  and  Direct  Memory  Access 
(DMA)  control  capabilities.  It  directs  control  and  data  between  the  attached 
bus  elements  by  referencing  each  terminal's  diial-port  memory  as  Its  oun  primary 
memory.  The  Mbus  can  support  up  to  14  terminals.  The  Mbus  Is  completely 
symmetrical  In  that  no  terminal  has  a  preferred  status  (Including  the 
AIDS  data  processor.) 

Data  may  be  transferred  between  any  two  terminals  attached  to  the  Mbus 
(GE  78).  Transfer  of  data  between  source  and  destination  modules  Is  Initiated 
by  the  source  terminal's  writing  a  source  command  block  (SCB)  into  its  dual~port 
memory  together  with  the  setting  of  its  command  flag  informing  the  Mbus  control¬ 
ler  of  the  completion  of  this  event.  An  SCB  Is  maintained  In  a  fixed  location 
in  each  terminal's  dual-port  memory.  It  contains  detailed  control  Information 
to  the  Mbus  controller.  Upon  receiving  a  terminal-generated  Interrupt,  the 
controller  copies  the  SCB  into  Its  own  message  processing  queue,  resets  the 
command  flag  (allowing  the  source  terminal  availability  of  its  SCB),  and  gener¬ 
ates  an  Interrupt  to  the  source  terminal.  The  controller  then  proceeds  to 
write  the  SCB  Into  the  destination  terminal's  command  block  (DCB)  and  then 
generates  an  Interrupt  to  the  destination  terminal.  At  this  point,  the  desti¬ 
nation  terminal  stores  control  Information  Into  Its  DCB  (Identifying  within 
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I  ts  dual-port  memory  where  the  data  Is  to  be  transferred),  sets  Its  command 
’flag  informing  the  controller  of  the  completion  of  this  event,  and  generates  an 
Interrupt  to  the  controller.  The  controller  resets  the  command  flag  and  then 
moves  the  data  from  the  source  to  the  destination,  whereupon  it  generates  Inter¬ 
rupts  to  both  source  and  destination  terminals  identifying  the  completion  of  the 
data  transaction. 


A  message  destination  may  Include  not  only  any  MIDER-resldent  device,  but 
also  an  AIDS  display  (on  the  Ibus)  or  any  external  system  interfacing  with  AIDS 
(on  the  Xbus).  Identification  of  the  Intended  destination  device  in  a  data 
transaction  is  established  by  the  bus  controller  through  the  use  of  its  "routing 
table."  This  table  defines  the  bus  routing  requirements  for  each  device;  in  the 
event  of  system  degradation,  the  data  processor  modifies  the  routing  table  to 
establish  the  revised  routing  requirements. 

The  bus  controller  has  the  capability  of  addressing  up  to  16K  in  each  ter¬ 
minal's  dual-port  memory  and  transmitting  variable  size  messages  ranging  from 
0  to  16K  words.  A  message  of  length  0  will  correspond  to  the  transfer  of  In¬ 
formation  solely  within  a  command  block  Itself. 


The  current  estimate  of  the  Mbus  transmission  time  is  approximately  100  Msec 
for  message  processing  overhead  with  a  5-  itaec  transfer  rate  per  word.  Based 
upon  an  estimated  AIDS  Mbus  load  factor  at  10  percent,  the  estimated  Mbus  access 
time  ranges  from  a  minimum  of  25  Msec  to  a  maximum  of  10  msec. 


(  ..3.1.3  Internal  Bus  (Ibus) 


The  Ibus  provides  the  Interface  between  a  MIDER  and  the  other  AIDS  com¬ 
ponents;  the  displays,  the  ICSs,  the  BIED,  Voice  Recognition,  Voice  Synthesis 
and  the  other  MIDER(s).  The  Ibus  Is  an  asynchronous  multiplex  bus  conforming 
to  the  MIL-STD-1553  protocol  (Air  Force  73).  This  protocol  is  a  command-response 
protocol  applicable  to  a  system  In  which  the  bos  controller  Is  either  the  source 
or  destination  of  most  data  exchanges. 


Command-response  protocol  requires  a  bus  controller  (BC)  which  issues  con¬ 
trol  directives  to  all  the  remote  terminals  (RTs)  connected  to  the  bus.  When 
acting  as  the  data  source,  the  BC  sends  a  "receive"  command  followed  by  the 
specified  number  of  data  words  to  the  RT;  In  response,  the  destination  RT  will 
transmit  a  "status"  command  to  the  BC  acknowledging  the  completion  of  data  recep¬ 
tion.  When  acting  as  the  Intended  data  destination,  the  BC  sends  a  "tranrimlt" 
command  to  the  RT;  in  response,  the  source  RT  will  transmit  a  "status"  command 
followed  by  the  specified  number  of  data  words  to  the  BC.  The  BC  also  can  act 
as  the  coordinator  of  data  transmissions  between  two  RTs.  The  BC  sends  a  re¬ 
ceive  command  to  the  Intended  destination  RT  and  a  "transmit"  command  to  the 
source  RT.  The  source  RT  subsequently  transmits  a  "status"  command  followed  by 
the  designated  number  of  data  words  and  the  destination  responds  with  a  status 
command. 


The  Ibus  is  a  dual  bus  structure  with  the  attached  terminals  acting  in  a 
^alf  duplex  mode.  Nominally,  both  buses  (known  as  the  A  and  B  bus)  are  active, 
kche  configuration  being  determined  by  the  data  processor.  Each  resident  MIDER 
contains  two  Ibus  bus  controllers,  each  comprised  of  an  AIDS  Digital  Terminal 
and  an  AIDS  Microcomputer.  The  AIDS  Digital  Terminal,  capable  of  functioning 
either  as  an  RT  or  BC,  contains  two  I/O  ports.  In  either  functional  mode  one 
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of  the  ports  is  active  on  the  A  or  B  bus  while  the  other  port  "listens”  to 
(i.e.,  monitors)  the  other  bus  activity.  Acting  in  a  bus  monitor  role,  the 
Digital  Terminal  will  assist  in  the  reconfiguration  of  the  AIDS  bus  structure  in 
the  event  of  a  bus  failure. 

The  Ibus  is  symmetrical  in  design  (analogous  to  the  Mbus)  with  all  the  at¬ 
tached  terminals  having  an  equal  status.  The  terminals  are  capable  of  blocking 
and  unblocking  data  transmissions  in  excess  of  32  words. 

The  current  estimate  of  the  Ibus  transmission  time  is  approximately  50  /usec 
for  message  processing  overhead  with  a  2C  Msec  transfer  rate  per  word.  The 
load  factor  and  access  time  for  the  Ibus  is  TBD. 

3.3. 1.4  External  Bus  (Xbus) 


The  Xbus  provides  the  Interface  between  AIDS  and  the  external  avionics  sub¬ 
systems.  It  is  an  asynchronous  multiplex  bus  conforming  to  the  MIL-STD-1S53 
operation  protocol.  Analogous  to  the  Ibus,  the  Xbus  operates  in  a  command- 
response  configuration;  however,  the  Xbus  controller  is  not  resident  within  the 
AIDS  configuration. 

The  Xbus  timing  characteristics  are  the  same  as  those  noted  for  the  Ibus. 

3. 3. 1.5  Video  Bus  (Vbus) 

The  Vbus  is  the  AIDS  video  transmission  system.  It  is  able  to  transmit 
sinultaneously  up  to  eight  different  channels  of  video  data  where  each  channel 
has  a  bandwidth  of  17  MHz.  Each  video  source  (i.e.,  raster  symbol  generators 
and  video  sensors)  transmits  its  video  at  a  distinct  RF  frequency.  Each  video 
receiver  (i.e.,  HUD,  MPD,  and  HIDER  video  receiver)  is  tunable  to  any  of  the 
video  transmission  frequencies.  Each  MIDER  includes  a  video  receiver  which 
accepts  sensor  video  and  transfers  this  video  to  a  raster  symbol  generator  for 
mixing  with  the  generated  symbology.  The  detailed  specification  of  the  Vbus  is 
TBD. 


3.3. 1.6  Mass  Memory  System 

In  the  AIDS  configuration,  the  mass  memory  system  is  a  disk  memory  system 
(minimum  capacity  400,000  words)  with  an  AIDS  microcomputer  as  the  mass  memory 
controller.  As  with  other  MIDER  modules  connected  to  the  Mbus,  the  mass  memory 
Mbus  interface  is  a  16K  dual-port  memory.  Data  to  be  written  into  mass  memory 
is  initially  transferred  from  the  source  element  by  the  Mbus  controller  into  the 
mass  memory  controller's  dual-port  memory.  A  write  request  includes  the  data's 
starting  address  and  number  of  words.  The  mass  memory  controller  subsequently 
initiates  a  DMA  transfer  of  the  data,  together  with  Identification  and  control 
information,  to  the  disk  controller's  input  data  buffer.  The  disk  controller 
then  empties  its  input  data  buffer  onto  the  designated  fixed-length  sector  blocks 
of  the  disk  storage  device.  The  mass  memory  controller  will  perform  tha  blocking 
and  unblocking  of  data  transmissions,  thus  providing  the  mass  memory  user  with 
a  transparent  mechanism  for  referencing  the  mass  memory.  That  is,  the  user 
references  the  mass  memory  as  a  continuous  random  access  memory. 
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Data  to  be  read  (l.e. ,  output)  from  mass  memory  Is  initiated  by  a  read  re¬ 
quest  being  sent  via  the  Mbus  controller  to  the  mass  memory  controller’s  dual¬ 
port  memory.  This  read  request  specifies  the  starting  address,  number  of  words, 
and  destination.  A  DMA  transfer  to  the  disk  controller,  identifying  the  re¬ 
quested  data,  is  then  performed;  the  contents  of  the  sector  blocks  are  then 
placed  into  the  disk  controller's  output  data  buffer.  This  data  is  subsequently 
transmitted  to  the  mass  memory  controller's  dual-port  memory  (via  a  DMA  transfer) 
and  then  to  the  destination  specified  in  the  read  request.  In  this  manner,  the 
data  processor  may  route  data  retrieved  from  mass  memory  directly  to  a  display 
or  ICS. 

The  device  controller's  error  detection  capabilities  include:  a  write  at¬ 
tempt  onto  protected  disk  memory,  exceeding  the  addressing  limits  of  the  mass 
memory,  the  occurrence  of  data  errors  (l.e.,  parity)  during  read-write  opera¬ 
tions,  and  data  transmission  timing  errors*  In  response  to  an  error's  occur¬ 
rence,  the  mass  memory  controller  will  retry  the  operation. 

The  estimated  processing  time  for  a  mass  memory  read  request  with  the  data 
processor  as  the  destination  is: 

o  time  of  read  request  transmission  from 

source  to  mass  memory  controller  *  0.2  msec 

o  response  time  of  device  controller  ■  30.0  msec 

o  transfer  rate  from  device  controller 

to  mass  memory  controller  *  0.002  msec/word 

o  Mbus  transfer  rate  *■  0.005  msec/word 

o  Mbus  access  time  (twice)  “  2.0  msec _ 

32.2  msec  +  0.007  msec/word 


A  MIDER  contains  from  two  to  four  RSGs,  each  of  which  accepts  a  display 
format  program  and  generates  the  equivalent  raster  representation  of  that  dis¬ 
play  format.  The  RSG  operates  at  either  of  two  video  frame  rates:  30  and  50 
Hz.  Selectable  resolution  modes  will  be  525,  875,  and  1023  TV  lines  per  video 
frame.  Within  the  AIDS  configuration,  the  HSD,  VSD,  HMD,  ADO,  and  TD  displays 
(reference  Section  3. 3. 1.9)  are  driven  by  RSGs.  During  low-level-light  day 
or  FLIR  night  conditions,  the  HUD  is  also  driven  by  an  RSG.  In  all  Instances, 
the  Vbus  routes  the  raster  video  Imagery  to  the  respective  displays. 

The  RSG  is  one  of  the  three  different  symbol  generators  in  AIDS;  the  HUD  and 
SAD  symbol  generators  are  the  other  two.  All  three  conform  to  the  Standard  AIDS 
Display  Interface  (SADI)  (Mlchener  and  Shelley  81).  SADI  display  primitives 
include:  lines  (solid,  dashed,  and  dotted),  text  (two  sizes),  arcs  and  circles, 
and  shaded  symbols.  By  means  of  aubplctures  (subroutines)  contained  in  the  SADI 
program,  both  S3nBbol  clipping  and  transformation  are  provided.  Symbol 
attributes  are:  blinking,  variable  intensity,  line  style,  and  line  width. 
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SADI  includes  both  a  display  Instruction  set  and  a  protocol  for  updating 
programs  written  In  this  Instruction  set.  The  interface  to  a  symbol  generator 
Includes  transmission  of  both  display  formats  and  updates  to  these  formats.  The 
display  formats  are  stored  In  the  mass  memory  and  are  transferred  by  data  pro¬ 
cessor  direction  to  a  symbol  generator  when  a  new  format  Is  required.  Updates 
to  a  format  are  generated  In  the  data  processor  and  are  transmitted  by  the  data 
processor  directly  to  the  s3rmbol  generator. 

3. 3. 1.8  Signal  Processor 

The  signal  processor  converts  acoustic  data  supplied  by  the  ASW  system  to 
Include  automatic  line  Integration  formats,  LOFAR  grams,  and  passive  B-scans. 

The  detailed  specification  of  the  signal  processor  Is  TBD. 

3. 3. 1.9  AIDS  Displays 

The  following  subsections  present  a  summary  discussion  of  the  functional 
and  physical  characteristics  of  the  AIDS  displays. 

Figure  3-3  Illustrates  the  placement  of  these  displays,  the  IGF,  and  the 
MCF  for  the  pilot's  station.  Figure  3-4  Illustrates  the  mission  officer  station. 

(The  ADU  shown  In  Figure  3-4  Is  not  included  in  the  AEU  mission  officer  station.) 

3. 3. 1.9.1  Head-Up  Display  (HUD) 

The  HDD  Is  the  principal  AIDS  flight-display.  It  consists  of  a  viewing  lens  mount¬ 
ed  between  the  pilot  and  the  windscreen  and  a  projection  unit  which  projects 
an  Image  onto  the  viewing  lens.  The  pilot  sees  the  HUD  Image  superimposed  on 
the  real  world  viewed  throu^  the  windscreen.  The  HUD  processing  operates  In 
two  modes:  stroke  or  raster  Image  refresh.  In  the  stroke  mode,  a  stroke 
symbol  generator  (residing  In  the  HUD)  generates  the  display  Image  using  a 
SADI  display  program.  In  the  raster  mode,  a  MIDER-resldent  RSG  (using  the 
same  SADI  program)  provides  raster  display  symbology  and  optional  sensor¬ 
generated  video  over  the  Vbus.  During  high  ambient  light  conditions  the  stroke 
mode  Is  used;  the  raster  mode  may  be  used  only  during  low  ambient  light  condi¬ 
tions.  Figure  3-5  Illustrates  the  HUD,  while  Figure  3-6  Is  a  representative 
display  format. 

3. 3. 1.9. 2  thiltlfunctlon  Display  (MFD) 

The  MFD  function  within  the  AIDS  configuration  Is  to  display  mission  and 
fll^t  data  as  a  combination  of  raster  refresh  symbology  and  sensor-generated 
video  Images.  Designed  for  use  during  high  ambient  light  conditions,  the  MFD 
Is  a  monochrome  CRT  with  gray  shading  capabilities.  The  MFD  has  two  screen 
sizes:  5  Inches  by  7  Inches  and  6.5  Inches  by  8.5  Inches.  The  resolution  Is 
800  TV  lines  at  picture  center  and  650  TV  lines  at  picture  corner.  Figure  3-7 
Illustrates  the  MFD. 

In  the  AIDS  configuration,  the  MFD  has  specific  applications  as  noted  below. 

3. 3. 1.9. 2.1  Vertical  Situation  Display  Format  (VSD).  The  VSD  displays  flight  data 
as  a  combination  of  raster  symbology  and  sensor-generated  video  (e.g.,  FLIR  or 
LLLTV).  The  VSD  also  provides  an  HUD  backup  capability.  The  VSD  has  a  screen 
size  of  5  Inches.  Figure  3-8  Is  a  representative  VSD  format. 
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FIGURE  3-4  -  Mission  Officer  Display  Placement 
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FIGURE  3-8  -  Representative  VSD  Format 
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'  3.3. 1.9. 2. 2  Horizontal  Situation  Display  Format  (HSD).  The  HSD  displays  flight  data 
as  a  combination  of  raster  symbology  superimposed  onto  either  an  electroni¬ 
cally  generated  map  or  a  mission  flight  plan.  The  HSD  has  a  screen  size  of  1/ 

Inches  by  7  inches.  The  HSD  also  provides  a  VSD  backup  capability.  Figure 
3-9  is  a  representative  HSD  format. 

3. 3. 1.9. 2. 3  Tactical  Display  (TD).  The  TD  displays  the  tactical  environment  for 
either  the  ASW  or  AEW  system.  The  TD  also  provides  a  backup  for  the  ADU.  In 
both  systems,  each  mission  officer  station  Includes  a  TD.  The  TD  has  a  6.5  by 
8.5  inch  screen.  The  TD  formats  are  TBD. 

3.3. 1.9. 2. 4  Auxiliary  Display  Unit  (ADU).  The  ADU  is  used  in  the  ASW  system 
to  display  formatted  acoustic  data.  The  ADU  also  serves  as  a  backup  to  the  TD. 

The  ADU  has  a  5  by  7  inch  screen.  The  ADU  formats  are  TBD. 


FIGURE  3-9  -  Representative  HSD  Format 

t 
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3. 3. 1.9. 3  Helmet  Display  System  (HDS) 

The  AIDS  HDS  consists  of  a  Helmet  Mounted  Display  (HMD)  and  a  Helmet  Posi¬ 
tion  Sensor  (HPS).  The  HMD  Is  comprised  of  a  helmet  and  visor  assembly  optl- 
c.’^lly  coupled  (via  a  lens  system)  to  a  miniature  CRT  display.  The  HMD  accepts 
raster  Imagery,  from  the  Vbus  and  digital  control  from  the  Ibus.  It  will 
display  symbology  onto  a  viewing  area  one  Inch  In  diameter.  Figure  3-10  Is  a 
representative  HMD  format. 

The  HPS  consists  of  a  cockpit  mounted  radiator  assembly  and  a  helmet  mounted 
sensor  system  coupled  to  an  AIDS  microcomputer.  The  radiator  assembly  generates 
a  magnetic  field  which  tracks  the  sensor  located  In  the  pilot's  helmet  as  a  means 
of  discerning  the  helmet's  position  and  orientation  with  respect  to  the  aircraft 
coordinates.  The  microcomputer  processes  pilot  mode  controls  (e.g.,  boreslght 
and  acquisition)  from  the  ICS  (via  the  Ibus)  as  well  as  performing  the  relevant 
coordinate  transformation  calculations  required  to  establish  the  helmet's 
position  and  orientation. 

3. 3. 1.9. 4  Situation  Advisory  Display  (SAD) 

Within  the  AIDS  configuration,  the  SAD  provides  an  annotation  of  displays 
using  alphanumeric  symbology.  For  the  pilot.  It  provides  system  monitoring 
and  engine  status  Information.  For  the  mission  officers.  It  provides  selected 
rack  status,  equipment  status,  and  data  link  parameters.  Designed  for  use 
during  high  ambient  light  conditions, -^he  SAD  is  a  monochrome  CRT  with  gray 
shading  capabilities.  It  has  a  usable  display  area  of  5  Inches  by  7  Inches 
with  a  resolution  of  900  TV  lines  at  picture  center  and  800  TV  lines  at  picture 
corner.  The  SAD  provides  a  SADI  subset.  This  subset  Includes  text,  vertical 
and  horizontal  lines,  and  symbols;  neither  subpictures  nor  attributes  are 
supported.  Figure  3-11  Illustrates  the  SAD;  Figure  3-12  Is  a  representative 
SAD  format. 
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FIGURE  3-10  -  Representative  HMD  Format 


22 


FIGURE  3-12  -  Representative  SAL  Format 
23 


75357~50 


3.3.1.10  Integrated  Control  Set  (ICS) 

The  ICS  is  the  primary  input  Interface  from  the  pilot  and  mission  officers 
to  AIDS  and  to  the  external  avionic  subsystems.  The  ICS  consists  of  two  control 
panels:  an  optional  Mode  Control  Panel  (MCP)  and  an  Integrated  Control  Panel 
(ICP).  The  ICS  contains  an  AIDS  microprocessor  which  controls  both  the  MCP 
and  ICP  while  also  functioning  as  an  Ibus  terminal.  The  ICS  microprocessor 
software  is  known  as  MFICS,  while  the  AIDS  data  processor  software,  which  inter¬ 
faces  with  MPICS,  is  known  as  DPICS.  The  AIDS  configuration  consists  of  one 
MCP  and  a  number  of  ICPs  dependent  upon  the  specific  mission  configuration. 

3.3.1.10.1  Mode  Control  Panel  (MCP) 

The  MCP  is  used  by  the  pilot  to  select  the  mission  mode.  The  MCP  also 
provides  a  visual  indication  of  the  current  mlsaion  mode.  It  consists  of  18 
touch-activated  switches,  each  mutually  exclusive.  Depression  of  a  switch 
causes  its  dedicated  legend  to  be  backll^ted,  together  with  the  sending  of  a 
corresponding  switch  selection  to  the  ICP.  Each  legend  will  consist  of  two 
rows  of  five  characters.  Figure  3-3  Illustrates  the  MCP. 

3.3.1.10.2  Integrated  Control  Panel  (ICP) 

The  ICP  is  used  to  control  external  avionic  systems,  to  position  sensors, 
to  control  all  the  AIDS  display  formats,  and  to  position  the  display  cursors. 

It  consists  of  two  main  groupings  of  tooch-activated  switches  (dedicated  and 
programmable)  and  an  analog  control  mechanism.  Figure  3-3  illustrates  the 
ICP. 


The  upper  group  of  18  fixed-legend  switches  controls  the  major  system  func¬ 
tions  and  configures  the  ICP  for  a  specific  action  sequence.  Depression  of  one 
of  these  fixed-legend  switches  enables  the  30  programmable-legend  lower  group. 

The  legal  functions  corresponding  to  the  fixed-legend  switch  will  be  displayed 
on  the  programmable  group  of  legends. 

The  programmable-legend  group  provides  up  to  five  levels  of  switch  inden¬ 
ture.  By  convention,  "level  of  indenture"  corresponds  to  the  number  of  switches 
that  must  be  pushed,  including  the  fixed-legend  switch  selection,  before  a  speci¬ 
fic  switch  is  displayed  on  the  programmable  group  of  legends.  During  a  pilot's 
command  sequence,  the  legends  of  all  switches  activated  are  displayed  on  a  char¬ 
acter  scratchpad  legend  to  provide  a  visual  history  of  the  command  sequence. 

In  the  event  that  the  last  switch  Indenture  requires  input  numerical  data,  a 
keyset  with  a  data  entry  capability  will  be  enabled.  Each  keyset  data  entry 
will  be  displayed  on  the  scratchpad;  by  means  of  a  "clear"  switch,  the  keyset 
entry  can  be  removed  from  the  scratchpad.  The  previous  higher  Indenture  level 
will  be  returned  to  by  means  of  a  "Return"  switch. 

The  analog  control  mechanism  is  a  force  stick.  When  enabled,  the  force 
stick  periodically  generates  two  digital  values  whose  magnitudes  depend  upon 
the  force  applied  to  the  stick.  These  digital  values  (X  and  Y)  are  sent  period¬ 
ically  to  the  AIDS  data  processor  where,  dependent  upon  the  device  the  pilot 
is  currently  controlling,  they  are  forwarded  either  to  an  external  avionic  sub¬ 
system  or  to  a  display  program. 
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4  3.3.1.11  Briefing  Information  Entry  Device  (BIED) 

The  BIED  is  a  microcompuCer-conCrolled  magnetic  cape  cartridge  unit  used  to 
input  briefing  information.  The  input  data  (specifying  the  mission)  is  intended 
for  both  AIDS  and  the  external  avionic  subsystems.  An  AIDS  microcomputer 
(interfaced  to  the  Ibus)  controls  the  transfer  of  data  from  the  tape  unit  as 
well  as  performing  error  detection  and  Built-in  Test  Equipment  (BITE) 
tests.  The  BIED  has  storage  capacity  for  48. 8K  words  and  a  transfer  rate 
of  1.2K  words/second.  During  flight,  the  BIED  may  also  be  used  to  record 
limited  mission  data,  thus  serving  as  a  debriefing  mechanism. 

3.3.1.12  Voice  Synthesizer 

Voice  synthesis  is  a  process  chat  electronically  converts  Che  output  of  an 
AIDS  data  processor  into  synthesized  human  speech.  The  voice  synthesizer  is 
capable  of  decoding  input  data  (from  the  AIDS  data  processor)  and  transforming 
it  into  electronically  synthesized  speech.  Specific  capabilities  include:  a 
limited  vocabulary  of  the  English  language,  rate  adjustment  and  voice  inflec** 
tlon.  By  means  of  a  remote  terminal,  the  voice  synthesizer  Interfaces  with 
the  AIDS  Ibus.  The  tentative  voice  synthesis  applications  for  the  V/STOL 
mission  Include  the  issuing  of  cautionary  and  warning  outputs  during  mission 
fault  occurrences  and  the  issuing  of  flight  critical  data  (e.g. ,  velocity  and 
altitude)  during  periods  of  high  visual  pilot  activity  (e.g.,  takeoff  and 
landing).  - 

# 

3.3.1.13  Voice  Recognition 

Voice  recognition  is  a  process  that  allows  the  pilot  to  communicate  directly 
(i.e.,  talk)  with  the  AIDS  data  processor.  The  voice  recognizer  is  capable 
(in  a  real-time  environment)  of  identifying  an  input  phrase  based  upon  a  com¬ 
parison  with  the  user's  previously  established  vocabulary.  In  response  to  valid 
identification,  display  of  the  commend  on  an  AIDS  display  provides  the  user  with 
visual  verification  of  the  command's  recognition. 

3.3.2  Digital  Processor  Input/Output  Utilization  Tables 

Tables  3-1  through  3-4  summarize  the  AIDS  data  processor  nominal  I/O  require¬ 
ments.  There  is  one  table  for  each  of  the  four  data  processor  configurations 
Illustrated  in  Figures  3-1  and  3-2.  These  configurations  are  Data  Processor 
1,  ASU  Data  Processor  2,  ASW  Data  Processor  3,  and  AEW  Data  Processor  2.  Note 
that  Data  Processor  1  is  configured  identically  in  both  the  AEW  and  ASW  sys¬ 
tems.  The  requirements  listed  in  the  tables  are  nominal  in  that  they  represent 
the  I/O  performed  in  a  completely  operational  system.  Obviously,  the  require¬ 
ments  for  and  allocation  of  I/O  differ  for  the  degraded  configurations. 

The  tables  are  partitioned  Into  the  I/O  which  occurs  on  each  of  the  three 

digital  buses  used  by  a  data  processor  (the  Mbus,  Xbus,  and  Ibus).  The  total 

I/O  requirements  for  the  Mbus  in  each  MIDEB.  Include  the  I/O  to  both  the  Xbus 

and  Ibus  peripherals  as  well  as  to  the  Mbus  peripherals.  Also,  the  total  re- 

quirement  for  the  Ibus  is  the  sum  of  the  requirements  in  the  two  AEW  tables 
and  the  three  ASW  tables.  The  values  used  for  the  number  of  input  and  output 
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TABLE  3-1.  DATA  PROCESSOR  1  INPUT/OUTPUT  UTILIZATION  (Page  1  of  2) 


BUS 

ADDRESS 

WORD 

SIZE 

CONNECTED 

EQUIPMENT 

NUMBER  OF 
INPUT  WORDS 

NUMBER  OF 
OUTPUT  WORDS 

TRANSFER  . 

RATE 

Mbus  Peripherals 

IliiiHB 

Xbus  RT  1 

-5 

Aperiodic 

TBD 

16 

Ibus  BC  1.1 

-5 

-5 

Aperiodic 

TBD 

16 

Ibus  BC  1.2 

-5 

-5 

Aperiodic 

TBD 

16 

Mass  Mamairy  1 

‘ 

.5  to  4000 

-20 

-5  to  .20 

5Hz 

Aperiodic 

TBD 

16 

RSG  1.1 
(to  HUD  or 
HMD) 

5 

60  Hz 

20  Hz 

Aperiodic 

TBD 

16 

RSG  1.2 
(to  VSO) 

• 

m 

rS  - 

60  Hz 

Aperiodic 

TBD 

16 

SC  1 

-5 

-5 

Aperiodic 

Xbus  Ptrlphcrals 


TBD 

16 

NAV 

13 

60  Hz 

14.26 

2 

20  Hz 

1 

1 

3 

Aperiodic 

TBD 

16 

JTIOS 

31 

- 

20  Hz 

TBD 

16 

COMM 

2 

20  Hz 

11 

» 

5  Hz 

• 

3 

ApeHodIc 

TBD 

16 

lEIS 

12.20 

5  Hz 

Aperiodic 

TBD 

16 

ULAIDS 

TBD 

m 

5  Hz 

• 

Aperiodic 

TBD 

16 

SOSTEL 

TBD 

m 

5  Hz 

• 

3 

Aperiodic 
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TABLE  3-1.  DATA  PROCESSOR  1  INPUT/OOTPOT  UTILIZATIOH  (Page  2  of  2) 


IS 

WORO 

CONNECTEO 

NUMBER  OF 

NUMBER  OF 

TRANSFER 

}0RESS 

SIZE 

EQUIPMENT 

INPUT  WOROS 

OUTPUT  WORDS 

RATE 

Ibus  Peripherals 

• 

to 

16 

HUO 

-10  to  -20 

60  Hz 

* 

100 

20  Hz 

>5 

5  to  700 

Aperiodic 

to 

16 

HMO 

4 

60  Hz 

.5 

.5 

Aperiodic 

0 

16 

VSO 

-5 

-5 

Aperiodic 

to 

16 

Pilot  ICS 

-3 

• 

20  Hz 

-5 

>5 

Aperiodic 

0 

16 

LSAO 

m 

-10  to  -30 

5  Hz 

I 

-5 

~  5  to  -  75 

Aperiodic 

0 

16 

RSAD 

• 

to  -30 

5  Hz 

-5 

-5  to  -75 

Aperiodic 

0 

16 

BIEO 

o 

o 

1 

-5 

Aperiodic 

0 

16 

Voice 

Recognizer 

'5 

-3000 

Aperiodic 

0 

16 

Voice 

Synthesizer 

-5 

-5  to  10 

Aperiodic 

0 

16 

Mbus  BC  2 

-25 

-25 

60  Hz 

0 

16 

Mbus  BC  3 

-25 

-25 

60  Hz 

75357J50 


TABLE  3-2.  ASW  DATA  PROCESSOR  2  IHPUT/OUTPUT  DTILI2ATI0H 


BUS 

■SI 

CONNECTED 

NUMBER  OF 

NUMBER  OF 

TRANSFER 

ADDRESS 

EQUIPMENT 

OUTPUT  WORDS 

RATE 

Mbus  PerlDherals 

TBO 

16 

Xbus  RT  2 

-5 

-5 

‘Aperiodic 

TBD 

16 

Ibus  BC  2.1 

*5 

-5 

Aperiodic 

TBO 

16 

Ibus  BC  2,2 

-5 

.5 

Aperiodic 

TBO 

16 

Mass  Memory  2 

- 

-20 

SH^ 

.5  to  ^4000 

.5  to  .20 

Aperiodic 

TBO 

16 

RS6  2.1 

m 

-100 

20Hz 

(to  HSO) 

.5 

-5 

Aperiodic 

TBO 

16 

RSG  2.2 

• 

TBD 

0.5Hz 

(to  TACCO  TO) 

-5 

-5 

Aperiodic 

TBO 

16 

RSG  2.3 

m 

TBO 

0.5Hz 

(to  SENSO  TO) 

-5 

-5 

Aperiodic 

TBO 

16 

RSG  2.4 
(to  SENSO  * 

TBO 

0.5Hz 

TACCO  TDs) 

.5 

Aperiodic 

Xbus  PerlDherals 

TBO 

16 

NAV 

13 

m 

60Hz 

14,26 

m 

20Hz 

TBO 

31 

- 

20Hz 

TBO 

16 

11 

- 

5 

TBD 

16 

ASW 

TBO 

TBD 

TBD 

Ibus  Peripherals 

TBO 

■■ 

HSO 

*5 

.5 

Aperiodic  ' 

TBO 

■■ 

TD( TACCO) 

-5 

-5 

Aperiodic 

TBO 

16 

TO(SENSO) 

-5 

.5 

Aperiodic 

TBO 

16 

SAO(TACCO) 

.5 

TBD 

TBO 

TBD 

16 

SAO(SENSO) 

-5 

TBO 

TBO 

TBD 

16 

Mbus  BC  1 

.25 

-25 

60Hz 

TBO 

16 

Mbus  BC  3 

.25 

-25 

60Hz 

9 


28 


75357J50 


TABLE  3-3.  ASW  DATA  PROCESSOR  3  INPUT/OUTPUT  UTILIZATION 


BUS 

ADDRESS 

WORD 

SIZE 

CONNECTED 

EQUIPMENT 

NUMBER  OF 
INPUT  WORDS 

NUMBER  OF 
OUTPUT  WORDS 

TRANSFER 

RATE 

Mbus  Perloherals 

TBD 

16 

Xbus  RT  3 

-5 

-5 

Aperiodic 

TBD 

16 

Ibus  BC  3,1 

-5 

-5 

Aperiodic 

Ibus  BC  3,2 

-5 

-5 

Aperl odi c 

Mass  Memory  3 

-5  to  4000 

-20 

5  to  20 

5Hz 

Aperiodic 

TBD 

16 

RSG  3,1 

(to  TACCO  ADU) 

"s 

-TBD 

-5 

O.SHz 

Aperiodic 

RSG  3,2 
(to  SENSO  ADU) 

-5 

TBD 

-5 

O.SHz 

Aperiodic 

SP  3.1 

(to  TACCO  ADU) 

-5 

-5 

Aperiodic 

SP  3  2 

(to  SENSO  ADU) 

-5 

•5 

Aperiodic 

Xbus  Peripherals 

TBD 

16 

ASW 

TBD 

TBD 

TBD 

Ibus  Peripherals 

ADU  (TACCO) 

-5 

-5 

ADU  (SENSO) 

.5 

-5 

I CP  (TACCO) 

-3 

-5 

20Hz 

-5 

-5 

Aperiodic 

I CP  (SENSO) 

-3 

• 

20Hz 

-5 

-5 

Aperiodic 

Mbus  BC  1 

.25 

-25 

60Hz 

Mbus  BC  2 

-25 

-25 

60Hz 
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TABLE  3-4.  AEH  DATA  PROCESSOR  2  IHPUT/OOTPyT  UTILIZATION  (Page  1  of  2) 


WORD 

CONNECTED 

NUMBER  OF 

NUMBER  OF 

TRANSFER 

SIZE 

EQUIPMENT 

INPUT  WORDS 

OUTPUT  WORDS 

RATE 

Mbus  Peripherals 


TBD 

16 

Xbus  RT  2 

-5 

-5 

Aperiodic 

TBD 

16 

Ibus  BC  2,1 

-5 

-5 

Aperiodic 

TBD 

16 

Ibus  BC  2.2 

-5 

-5 

Aperiodic 

TBD 

16 

Mass  Memory  2 

-5  to  4000 

-20 

5  Hz 

.5  to  20 

Aperiodic 

TBD 

16 

RS6  2.1 

100 

20  Hz 

(to  HSD) 

5 

5 

Aperiodic 

TBD 

16 

RS6  2,2 

A 

TBD 

0.5  Hz 

(to  CICO  TD) 

5-  - 

5 

Aperiodic 

TBn 

16 

RSG  2.3 
(to  AC01  TD) 

TBD 

0.5  Hz 

Aperiodic 

TBD 

16 

-5 

-5 

TBD 

-5 

RSG  2,4 
(to  A002  TD) 

0.5  Hz 

Aperiodic 

*5 

TBD 

16 

SC  2,1 

-5 

-5 

Aperiodic 

TBD 

16 

SC  2.2 

-5 

-5 

Aperiodic 

TBD 

16 

SC  2,3.. 

-5 

-5 

Aperiodic 

Xbus  Peripherals 

TBD 

16 

NAV 

13 

m 

60  Hz 

14,26 

• 

20  Hz 

TBD 

16 

JTIDS 

31 

- 

20  Hz 

TBD 

16 

COMM 

11 

• 

5  Hz 

TBD 

16 

AEW 

TBD 

TBD 

TBD 
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TABLE  3-4.  AEW  DATA  PROCESSOR  2  INPUT/OUTPUT  UTILIZATION  (Page  2  of  2) 


BUS 

WORD 

CONNECTED 

NUMBER  OF 

NUMBER  OF 

TRANSFER 

ADDRESS 

SIZE 

EQUIPMENT 

INPUT  WORDS 

OUTPUT  WORDS 

RATE 

I  bus  Peripherals 


TBD 

16 

HSD 

.5 

,5 

Aperiodic 

TBD 

16 

TD(CICO) 

-5 

.5 

Aperiodic 

TBD 

16 

TD(AC01 ) 

-5 

>5 

Aperiodic 

TBD 

16 

TD(AC02) 

.5 

-5 

Aperiodic 

TBD 

16 

SAD (Cl CO) 

.5 

TBD 

TBD 

TBD 

16 

SAO(ACOI) 

.5 

TBD 

TBD 

TBD 

16 

SA0(AC02) 

-5 

TBD 

TBD 

TBD 

16 

ICP(CICO) 

-1-  - 

• 

20  Hz 

..5 

-5 

Aperiodic 

TBD 

16 

ICP(ACOI) 

>3 

20  Hz 

-5 

-5 

Aperiodic 

TBD 

16 

ICP(AC02) 

-3 

20  Hz 

-5 

- 

Aperiodic 

TBD 

16 

rt>us  BC  1 

^25 

-25 

60  Hz 
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words  and  the  transfer  rates  are  derived  from  the  description  of  the  program 
interfaces  described  in  Section  3.3.4.  If  an  input  or  output  message  is  of 
variable  size,  the  number  of  words  is  expressed  as  a  range,  for  example,  "5  to 
4000.”  If,  on  the  other  hand,  there  are  multiple  fixed-size  messages,  each 
message  is  listed  separately,  for  example  "12,  20." 

Included  as  aperiodic  output  words  to  each  of  the  symbol  generators  are  the 
words  required  to  load  the  symbol  generator  with  a  new  format.  These  words 
are  not  actually  transmitted  from  the  data  processor;  rather  they  are  trans¬ 
mitted  from  the  mass  memory.  The  words  are  included  in  these  tables  for  com¬ 
pleteness. 

For  the  Mbus  peripherals,  a  numbering  scheme  is  used  to  uniquely  identify 
each  component.  Each  component  name  is  followed  by  a  digit  identifying  the 
MIDER.  Further,  if  the  component  is  duplicated  in  the  MIDER,  a  second  digit 
is  used. 


3.3.3  Digital  Processor  Interface  Block  Diagram 

For  the  AEU  and  ASW  versions  of  AIDS,  Figures  3-1  and  3-2  in  Section  3.2.1 
illustrate  the  interconnection  of  the  AIDS  hardware  modules  and  the  connections 
between  AIDS  and  external  sensors  and  subsystems. 

3.3.4  Program  Interface  Descriptions  — 

The  AIDS  program  interfaces  may  be  divided  into  three  groups:  the  interfaces 
between  AIDS  software  and  AIDS  firmware  programs,  the  Interfaces  between  AIDS 
software  programs  and  the  external  avionics  subsystems,  and  the  off-line  inter¬ 
faces  between  AIDS  software  programs  and  program  generation  programs. 

This  section  describes  the  purpose  of  each  Interface.  The  details  of  the 
interfaces  will  be  contained  in  Interface  Design  Specifications.  The  Interface 
details  are  currently  TBD.  In  each  following  subsection,  each  interface  is 
introduced  in  a  paragraph.  The  Introductory  paragraphs  are  followed  by  a  table 
which  lists,  for  each  Interface,  the  physical  character  of  the  Interface,  the 
logical  data  transferred  over  the  Interface,  and  estimates  of  the  data  volume 
and  interface  bandwidth.  The  data  volume  is  the  number  of  16-blt  words  required 
for  the  data.  The  bandwidth  is  the  number  of  16-blt  words  per  second.  If  an 
Interface  is  used  only  for  program  loading  or  to  report  exception  conditions. 
Its  bandwidth  is  described  as  "Nil."  For  descriptive  purposes  in  the  tables 
only,  one  of  the  interfacing  programs  is  labeled  the  "A  Side";  the  other  is 
labeled  the  "B  Side.” 

3.3.4. 1  AIDS  Firmware  Interface  Descriptions 

For  the  Interfaces  listed  below,  the  two  programs  which  logically  Interface 
are  described  as  the  interfacing  programs.  In  actuality,  several  programs  may 
be  involved  in  the  interface.  For  example,  the  interface  defined  as  the  "DPtcS/ 
MPICS”  interface  requires  an  Interface  between  OSS  and  the  Mbus  controller,  an 
Interface  between  the  Mbus  controller  and  the  MIDER  Ibus  terminal,  and  an  inter¬ 
face  between  the  MIDER  Ibus  controller  and  the  ICS  Ibus  terminal. 
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The  AIDS  operational  interfaces  are: 

a.  The  Operational  Support  Software  (0SS)/Mbu8  Controller  Interface  provides 
the  OSS  with  I/O  access  to  all  the  equipment  connected  to  the  Mbus,  Ibus,  and 
Xbus.  The  Interface  includes  a  unique  address  for  all  equipment  on  all  the  buses. 
Thus  the  OSS  may  transmit  messages  to  all  the  equipment  as  if  they  were  attached 
to  a  single  bus.  The  Mbus  controller  is  responsible  for  knowledge  of  the  actual 
us  addresses  and  the  individual  bus  protocols.  The  Mbus  controller  also  allows 
the  OSS  to  transmit  messages  whose  sizes  are  larger  than  those  allowed  on  the 
various  buses.  The  Hbus  controller  partitions  a  large  message  into  a  linked  set 
of  messages  whose  sizes  conform  to  bus  requirements. 

b.  The  OSS/Ibus  Controller  Interface  provides  the  OSS  with  control  over 
which  Ibus  and  Ibus  controller  the  data  processor  uses  for  communicating  with 
Ibus  peripherals.  The  interface  also  provides  the  OSS  with  Ibus  controller 
and  Ibus  status. 

c.  The  OSS/Xbus  Terminal  interface  provides  the  OSS  with  control  over  which 
Xbus  the  data  processor  uses  for  communicating  with  the  external  avionics  sub¬ 
systems  on  the  Xbus.  The  interface  also  provides  the  OSS  with  the  Xbus  a’d  Xbus 
terminal  status. 

d.  The  OSS /Mass  Memor>'  system  interface  allows  the  OSS  to  access  variable- 
length  blocks  at  random  addresses  in  tha.  mass  memory.  The  access  may  be  a  write 
access  or  a  transmit  access.  A  transmit  access  directs  the  mass  memory  con¬ 
troller  to  transmit  the  contents  of  a  set  of  blocks  to  a  specified  destination. 
Examples  of  data  transmissions  are  transmitting  a  display  format  to  a  symbol 
generator  and  transmitting  a  program  module  to  the  data  processor. 

e.  The  Operational  Display  Software  (ODS)  Raster  Symbol  Generator  Interface 
provides  the  raster  symbol  generators  with  ODS-selected  formats  and  ODS-generated 
format  updates.  The  interface  conforms  to  SADI. 

f.  The  ODS/ Scan  Converter  interface  provides  the  scan  converter  with  radar 
sensor  control  commands  and  video  routing  commands,  and  provides  ODS  with  scan 
converter  status  messages. 

g.  The  ODS/Signal  Processor  Interface  provides  the  signal  processor  with 
control  commands  for  formatting  acoustic  data  according  to  mission~~o€f^er  re¬ 
quested  formats.  The  interface  provides  the  ODS  with  signal  processor  status 
messages. 

h.  The  DPICS/MPICS  interface  DPICS  with  commands  and  status  input  from 
MPICS  and  provides  MPICS  with  error  messages  generated  by  DPICS. 

i.  The  OSS/BIED  Interface  provides  the  OSS  with  the  mission  description 
records  on  the  BIED  and  provides  the  BIED  with  read  and  rewind  commands. 

j.  The  OSS/Volce  Recognizer  interface  provides  the  OSS  with  recognized 
commands  and  voice  recognizer  status  and  provides  the  voice  recognizer  with 
crewmember  voice  profiles. 
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k.  The  OSS/Voice  Synthesizer  Interface  provides  the  voice  synthesizer  with 
phrases  to  synthesize  and  with  desired  voice  characters  and  provides  the  OSS 
with  the  voice  synthesizer  status. 

l.  The  ODS/Miltlfunction  Display  System  Interface  provides  the  MFD  with  video 
channel  selection  commands  and  provides  the  ODS  with  status.  This  Interface 
is  used  for  the  VSD,  BSD,  each  TO,  and  each  ADD. 

m.  The  ODS/HOS  interface  provides  the  HOS  with  video  channel  selection  commands 
and  with  helmet  display  system  positioning  mode  commands.  The  Interface  provides 
the  ODS  with  helmet  position  and  with  HDS  status. 

n.  The  Operational  Display  Software/Status  Advisory  Display  (ODS/SAD)  Interface 
provides  the  SADs  with  ODS-selected  formats  and  ODS-generated  format  updates.  The 
Interface  conforms  to  SADI. 

o.  The  ODS /HDS  Interface  provides  the  HUD  with  ODS-selected  formats  and 
ODS-generated  format  updates.  The  Interface  conforms  to  SADI.  The  ODS/HUD  interface 
also  provides  the  HUD  with  commands  which  designate  either  stroke  or  raster  mode 
and,  for  raster  mode,  with  video  channel  selection  commands,  when  operating  in 
stroke  mode. 

p.  The  OSS/MIDER  interface  provides  for  inter-MIDER  Information  exchange. 

The  interface  comprises  periodic  messages  transmitted  in  both  directions  which 
describe  both  the  status  of  all  the  HIDER  components  and  the  processing  functions 
currently  being  performed  in  the  MIDER. 

The  contents  of  the  AIDS  software/AIDS  firmware  interfaces  are  described  in 
Table  3-5. 

3. 3. 4. 2  External  Avionic  Subsystems  Interface  Descriptions 

AIDS  has  interfaces  with  a  variety  of  external  avionic  subsystems.  These 
subsystems  provide  AIDS  with  navigation,  communication,  command  and  control, 
aircraft  status  information,  and  mission  data.  AIDS  will  supply  these  subsystems 
with  crew  commands  communicated  through  the  ICS  and  voice  recognition. 

The  AIDS  external  interfaces  are: 

a.  The  AIDS/NAV  Interface  provides  AIDS  with  navigation  data.  AIDS  provides 
NAV  with  pilot  Inputs  regarding  navigation  updates. 

b.  The  AIDS/JTIDS  Interface  provides  AIDS  with  command  and  control  information 
transmitted  to  the  aircraft  from  shore-based,  ship-based,  or  air-based  command 

and  control  centers.  JTIDS  also  provides  TACAM  data.  AIDS  provides  JTIDS  with 
pilot  commands  regarding  control  of  JTIDS. 

c.  The  AIDS/COMM  interface  provides  AIDS  with  the  current  assignments  of 
the  UHF,  VHF,  IFF,  and  radar  beacon.  AIDS  provides  COMM  with  pilot  commands 
for  controlling  the  communication  equipment. 

d.  The  AIDS/IEIS  Interface  provides  AIDS  with  the  status  of  the  aircraft 
engines . 
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e.  The  AIDS/ULAIDS  interface  provides  AIDS  with  the  status  of  all  air¬ 
craft  equipment  not  controlled  by  one  of  the  other  external  avionic  subsystems. 
This  equipment  Includes  cockpit  environment  control,  fuel,  flaps,  and  landing 
gear.  ULAIDS  also  serves  as  the  flight  data  recorder;  consequently,  AIDS  will 
periodically  provide  ULAIDS  with  the  AIDS  system  status. 

f.  The  AIDS/SOSTEL  interface  provides  AIDS  with  the  status  of  the  air¬ 
craft's  electrical  supply  system. 

g.  The  AIDS/AEU  Interface  provides  AIDS  with  the  tactical  data  base. 
AIDS  provides  AEU  with  mission  officer  control  of  the  AEW  system. 

h.  The  AIDS/ASW  interface  provides  AIDS  with  processed  acoustic  data  and  with 
a  tactical  data  base.  AIDS  provides  ASW  with  mission  officer  control  of  the 
ASW  system. 

The  contents  of  the  AIDS/extemal  avionics  subsystem  interfaces  are  de¬ 
scribed  in  Table  3-6. 

3. 3. 4. 3  Program  Generation  Interface  Descriptions 

The  program  generation  interfaces  are  not  real-time  interfaces.  Rather, 
they  involve  inclusion  of  the  tables  generated  by  the  AIDS  formatting  components 
into  AIDS  software  modules.  Whether  £he  tables  are  included  before  or  after 
compilation  of  the  module  is  TBD. 

a.  The  AIDS  Display  Formatter  (ADF)/ ODS  interface  provides  AIDS  with  for¬ 
mat  tables  for  all  the  AIDS  formats.  These  tables  result  from  the  translation 
of  GRADS  descriptions  of  the  AIDS  formats.  For  each  format,  the  ADF  generates 
two  files  which  are  stored  in  the  AIDS  mass  memory.  One  contains  the  SADI 
program  corresponding  to  the  format;  the  other  contains  the  data  required  to 
dynamically  change  and  update  the  SADI  program.  During  the  mission,  the  SADI 
program  file  is  loaded  into  and  executed  by  a  symbol  generator  and  the  change 
data  file  is  loaded  into  and  referenced  by  the  AIDS  software.  The  ADF/AIDS 
interface  detailed  description  is  TBD. 

b.  The  AIDS  Command  Formatter  (ACF)/DPICS  interface  provides  OPICS  with 
the  command  tables  which  describe  Che  required  interpretation  of  all  the  possible 
ICP  inputs.  These  tables  result  from  the  translation  of  Che  ACOL  specification 
of  the  permissible  ICP  input  sequences.  A  separate  command  cable  is  stored  on 
the  mass  memory  for  each  possible  ICP  configuration  (i.e.,  pilot,  TACCO,  SENSO, 
CICO,  and  ACO).  Each  command  Cable  contains  for  each  command  the  command's 
ultimate  destination,  a  command  code,  and  an  indication  of  whether  the  command 
includes  a  keyset  entered  value  or  whether  the  command  invokes  the  force  stick. 

The  ACF/DPICS  interface  is  defined  in  the  "AIDS  Command  Formatter  User's  Guide" 
(King  80). 

c.  The  AIDS  Equipment  Formatter  (AEF)/0DS  interface  provides  ODS  with  High 
Order  Language  (HOL)  declarations  of  the  equipment-monitoring  data  base.  This 
equipment-monitoring  data  base  contains  a  hierarchical  specification  of  all  the 
aircraft's  equipment,  Che  warning  and  caution  tolerance  values  for  each  equip¬ 
ment,  and  an  indication  of  which  display  formats  contain  which  equipment  status 
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values.  The  details  of  the  AEF/ODS  Interface  are  TBO.  A  description  of  the  AEF 
Is  contained  In  the  "AIDS  Operational  Display  Software  Program  Performance  Spe¬ 
cification”  (Roth  77). 

3.3.5  Functional  Description 


This  section  Introduces  the  19  functional  components  of  the  AIDS  software. 
Detailed  specifications  of  the  Inputs,  processing,  and  outputs  of  each  of  these 
functions  are  contained  In  the  Section  3.4  subsections.  Table  3-7  summarizes 
the  functional  processing  required  for  the  pilot  displays  In  the  V/STOL  aircraft. 
The  corresponding  tables  for  the  ASU  and  AEU  crew  stations  are  TBD.  These  tables 
contain  the  essences  of  the  processing  that  must  be  performed  by  the  functions 
described  In  this  section.  The  column  entries  In  these  tables  reference  the 
display  formats  that  are  described  In  Sections  3.4.15,  3.4.16,  and  3.4.17. 

The  AIDS  software  consists  of  "application  programs”  and  "support  software.” 
The  application  programs  are  a  set  of  Information  processing  subsystems,  each 
of  which  Is  responsible  for  a  different  class  of  aircraft  or  mission  Information 
display.  These  subsystems  for  the  V/STOL  aircraft  are:  flight  data  display, 
equipment  monitoring,  communication  data  display,  AEW  display,  and  ASW  display. 
Together,  these  subsystems  constitute  the  Operational  Display  Software  (ODS). 
The  support  software  Includes  all  the  procedures  which  provide  common  services 
to  each  of  the  ODS  subsystems.  The  Operational  Support  Software  (OSS)  Is  a 
combination  of  all  these  procedures. 

The  OSS  provides  the  environment  in  which  the  applications  software  runs. 
^  (This  environment  may  be  considered  a  virtual  machine  with  a  well-defined  soft- 
'  ware  Interface,  which  is  applicable  to  a  wide  variety  of  processor  and  system 
architectures.  When  the  underlying  physical  machine  changes,  the  software 
Interface  to  the  virtual  machine  will  remain  the  same. 

The  services  provided  by  the  OSS  may  be  divided  Into  four  general  categories: 
executive  functions.  Input /output  functions,  file  system  functions,  and  recon¬ 
figuration  control.  Executive  functions  Include  processor  and  primary  memory 
allocation  and  Intertask  communication  and  coordination.  The  Input/output  func¬ 
tions  govern  all  transactions  between  an  AIDS  data  processor  and  any  external 
device.  File  system  functions  provide  access  to  data  organized  as  units  of  re¬ 
lated  Information.  The  reconfiguration  control  functions  maintain  alternative 
sources  for  critical  data  and  help  the  applications  functions  to  determine  which 
peripherals  are  usable. 

The  OSS  is  divided  into  three  levels:  the  lowest  level  of  the  support  soft¬ 
ware  Is  SDEX/M;  the  next  level,  the  AIDS  Operating  System;  and  the  highest 
level,  the  device-specified  I/O  controllers.  SDEX/M  Is  a  standard  real-time 
executive  for  the  AN/AYK-14  and  the  AN/tJYK-20  computers  (NAVELEX  78),  and  as 
such  It  provides  the  operating  system  environment  necessary  to  support  the  exe¬ 
cution  of  CMS-2M  and  assembly  language  programs  for  the  AIDS.  The  executive 
provides  services  such  as  Initialization,  task  management,  task  synchronization, 
I/O  handling,  event  management  which  Includes  both  Interrupt  and  error  handling, 
and  system  monitoring.  Inherent  In  the  task  management  service  Is  memory  man- 
^agement  and  memory  mapping  capabilities  which  are  transparent  to  the  user. 
^3DEX/M  Is  under  Joint  configuration  control  of  NAVELEX  and  NAVAIR  and  will  be 
Government-furnished  to  the  software  designer. 


49 


TABLE  3-7.  PILOT  DISPLAY  REQUIREMENTS  SUMMARY 


"  The  level  of  the  OSS  above  SDEX/M  is  the  AIDS  Operating  System  (AOS).  The 
AIDS  Operating  System  includes  all  those  mission-specific  functions  normally 
allocated  to  an  operating  system  which  are  not  included  in  the  SDEX/M  Executive. 
For  AIDS,  these  functions  are:  Mbus  I/O,  a  file  system  which  utilizes  the  mass 
memory  system,  performance  monitoring,  system  initialization,  reconfiguration, 
and  overlay  processing. 

The  highest  level  of  the  OSS  contains  the  device  drivers  for  each  of  the 
different  AIDS  hardware  modules.  Note  that  each  of  these  drivers  uses  the  Mbus 
I/O  function  of  the  AIDS  Operating  System.  The  device  drivers'  functions  are: 
Briefing  Information  Entry,  ICS  switch  processing,  ICS  force  stick  processing, 
Hands-on-Throttle-and-Stlck  (HOTAS)  processing,  voice  recognition.  Graphic  Real- 
Time  Application  Display  Support  (GRADS),  voice  synthesis,  and  video  input 
(l.e.,  FLIR  and  LLLTV)  processing.  The  three  tactile  input  functions  (ICS 
switch  processing,  ICS  force  stick  processing,  and  HOTAS  processing)  are 
together  known  as  DP ICS. 

Each  of  the  information  display  subsystems  uses  ICS  switch  processing  for 
control  input  and  GRADS  for  display  output.  Additionally,  a  given  display  sub¬ 
system  uses  one  or  more  of  the  other  six  driver  functions  for  communicating  with 
the  crew.  Figure  3-13  Illustrates  the  composition  of  the  AIDS  software  in  terms 
of  the  levels  discussed  above.  The  vertical  arrows  through  the  levels  Indicate 
which  lower  levels  are  accessible  from  a  higher  level. 
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FIGURE  3-13  -  AIDS  Functional  Partitioning 
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To  further  explain  the  functional  partitioning  of  the  AIDS  software,  Tables 
3-8  through  3-10  indicate  the  responsibilities  and  processing  frequency  of  the 
AIDS  functions.  Table  3-8  indicates  -^hich  AIDS  functions  are  active  in  the  var¬ 
ious  mission  modes.  Table  3-9  indicates  which  AIDS  hardware  modules  are  con¬ 
trolled  by  which  AIDS  function.  Finally,  Table  3-10  specifies  the  execution 
frequency  of  each  AIDS  function. 

The  following  19  subsections  describe  briefly  the  characteristics  of  each 
of  the  AIDS  functions.  The  most  general-purpose,  commonly  used  functions  are 
described  first.  Subsections  1  through  6  describe  the  AIDS  Operating  System 
functions,  7  through  9  describe  the  DPICS  functions,  10  through  H  describe  the 
ocher  driver  functions,  and  15  through  19  describe  the  display  subsystems. 

3.3.5. 1  Input/Output 

The  I/O  function  of  Che  OSS  multiplexes  all  the  input  and  output  requests 
of  the  various  application  programs.  These  requests  are  multiplexed  through 
Che  single  input  and  output  channel  provided  by  the  Mbus.  The  1/0  function  sup¬ 
ports  three  forma  of  I/O;  OUTPUT  MESSAGE,  INPUT  SINGLE  MESSAGE,  and  INPUT 
PERIODIC  MESSAGES.  Both  the  OUTPUT  MESSAGE  and  INPUT  SINGLE  MESSAGE  form  are 
I/O  with  wait;  that  is,  the  requesting  application  process  is  suspended  until 
Che  I/O  operation  has  been  completed.  For  an  INPUT  SINGLE  MESSAGE  request,  I/O 
completion  occurs  on  the  arrival  of  the  Mbus  input  message  identified  by  the 
parameters  in  the  request. 

The  INPUT  PERIODIC  MESSAGES  request  supports  the  input  of  data  which  is  pro¬ 
cessed  periodically  by  an  applications  process.  Examples  of  such  data  are  flight 
parameters  from  Che  Navigation  subsystem  and  force  stick  values  from  MPICS. 
Once  an  INPUT  PERIODIC  MESSAGES  request  has  been  received,  Che  OSS  continues  to 
accept  Che  input  message  Identified  by  Che  request  until  a  corresponding  STOP 
PERIODIC  INPUT  request  is  received.  During  the  actual  transmission  of  the  peri¬ 
odic  message  into  Che  requesting  tasks 's  input  buffer,  Che  OSS  blocks  Che  re¬ 
questing  process  from  running.  Further,  Che  OSS  increments  a  sequence  counter 
in  Che  input  buffer  following  Che  completion  of  each  input  message  transmission. 
Thus  when  an  application  process  must  ensure  chat  multiple  words  in  the  input 
buffer  arrived  in  the  same  message,  the  process  must  verify  that  Che  value  of 
the  sequence  counter  is  Che  same  before  and  after  accessing  the  multiple  words. 


Figure  3-14  illustrates  Che  processing  flow  of  the  four  OSS  I/O  procedures. 
Figure  3-15  Illustrates  Che  processing  of  Che  I/O  function  in  response  to  an 
input  message  arrival. 

3. 3. 5. 2  File  System 

The  file  system  function  of  the  OSS  provides  the  application  programs  with 
file  system  interface  Co  the  mass  memory  system.  The  file  system  supports  only 
those  file  types  and  file  access  techniques  required  by  AIDS.  These  types  are 
fixed-length  files  which  are  read  and  written  in  their  entirety  and  a  single 
variable-length  file,  Che  Log,  which  is  written  sequentially.  The  majority 
of  Che  files  are  read-only;  these  files  contain  all  the  programs  (i.e.,  data 
processor,  microprocessor,  and  SADI  programs)  which  constitute  the  AIDS. 
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TABLE  3-8.  AIDS  FUNCTION  VERSUS  MISSION  MUUt 
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TABLE  3-10.  ALLOCATION  OF  AIDS  HARDWARE  MODULES  TO  SOFTWARE  FUNCTION 
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FIGURE  3-14  -  I/O  Request  Processing 
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FIGURE  3-15  -  Message  Arrival  Processing 
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The  read/wrlCe  fixed-length  files  Include  the  BIED  mission  data  and  the  current 
system  status.  Finally,  the  Log  contains  all  data  collected  and  recorded  during 
the  mission.  The  allocation  of  these  files  on  the  mass  memory  Is  Illustrated 
In  Figure  3-16. 

The  file  systen  provides  four  file  access  procedures:  READ  FILE,  WRITE 
FILE,  CREATE  FILE,  and  LOG.  Files  accessed  by  READ  FILE  and  WRITE  FILE  must 
have  been  allocated  either  at  a  system  generation  or  dynamically  via  CREATE 
FILE.  The  OSS  maintains  a  file  directory  which  contains  for  each:  the  file's 
start  address.  Its  length.  Its  access  parameter  (read-only  or  read/write),  time 
of  last  access,  type  of  last  access  (read  or  write)  and  Identification  of  the 
process  requesting  the  last  access.  In  response  to  the  READ  FILE  or  WRITE 
FILE,  the  entire  file  Is  transferred. 


Log  File 
Unused 

Read/Write  Files 
(allocated  dynamically) 


Read  Only  Files 

(allocated  at  system  generation) 


FIGURE  3-16  -  Maas  Memory  File  Allocation 
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Write  access  to  the  Log  is  provided  by  the  LOG  procedure^  In  response  to  a 
LOG  request,  the  OSS  appends  the  information  to  be  logged  at  the  end  of  the  Log. 
As  Illustrated  in  Figure  3-16,  the  Log  grows  down  from  the  top  of  the  mass 
memory,  while  the  dynamically  allocated  files  are  allocated  up  from  the  top  of 
the  statically  allocated  files.  If  the  capacity  of  the  mass  memory  Is  exceeded, 
all  further  CKEAIE  FILE  requests  cause  error  notifications  and  further  LOG  re¬ 
quests  overwrite  the  oldest  entries  in  the  Log. 

Figure  3-17  illustrates  the  processing  flow  of  the  four  file  system  pro¬ 
cedures. 
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FIGURE  3-17  -  I/O  Procedure  Processing 
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3. 3. 5. 3  Perfortaance  Monitoring 

The  Performance  Monitoring  function  of  the  OSS  provides  services  Intended 
to  promote  evaliiatlon  of  the  AIDS  system  performance,  where  performance  refers 
to  the  throughput  performance  of  the  software  and  hardware,  the  performance  of 
the  crew  when  Interacting  with  AIDS,  and  the  performance  of  the  software  In 
response  to  both  software  and  hardware  failures.  Effective  performance  monitor¬ 
ing  requires  active  participation  by  all  the  AIDS  software  modules.  By  providing 
easy-to-use  services,  the  Performance  Monitoring  function  encourages  this  parti¬ 
cipation.  The  services  provided  are  data  recording,  error  notification,  and 
software  timing. 

The  data  recording  service  allows  an  application  program  to  supply  data  to 
be  recorded  and  a  code  Identifying  the  data.  The  data  recording  function  will 
then  time  stamp  the  data,  format  the  data  Into  a  standard  data  recording  message, 
and  log  the  message  on  the  output  device  currently  In  use  as  the  Log.  During  a 
mission,  the  Log  will  be  the  mass  memory  system;  during  system  development  and 
evaluation  the  Log  could  be  an  attached  Integration  system  or  a  line  printer. 
Examples  of  data  which  will  be  recorded  are  software  timing  statistics,  hardware 
and  software  failures,  and  crew  response  times.  The  generation  of  failure  mes¬ 
sages  and  timing  statistics  Is  explained  below. 

The  Performance  Monitoring  function  provides  a  centralized  error  reporting 
service  to  encourage  detection  and  reporting  of  errors.  This  service  allows 
an  application  program  to  report  an  error  where  the  report  Includes  a  character 
string  describing  the  error,  a  code  describing  the  error  severity,  and  a  code 
describing  the  appropriate  action.  The  severity  code  Is  either  Warning, 
Caution,  or  Advisory.  The  action  requested  by  the  application  program  may  be 
either  to  allow  the  program  to  continuer-execution  or  to  terminate  the  program. 
Centralizing  the  error  reporting  facilitates  modifying  the  standard  error 
response  as  a  function  of  the  system's  operating  mode.  That  Is,  a  different 
response  Is  warranted  during  debugging,  system  evaluation,  and  fleet  operation. 
Figure  3-18  Illustrates  the  processing  flow  of  the  RECORD  DATA  and  SIGNAL 
ERROR  procedures. 

The  third  service  provided  by  Performance  Monitoring  Is  software  execution 
timing.  This  service  allows  the  application  program  to  time  any  arbitrary  se¬ 
quence  of  program  statements.  The  statistics  gathered  by  the  timing  service 
Include  the  number  of  times  the  sequence  was  executed  and  the  average  and  maxi¬ 
mum  execution  times  for  the  sequence.  By  timing  various  sequences  during  sys¬ 
tem  debugging  and  evaluation,  the  software  may  be  optimized  to  Increase  system 
throughput.  Further,  the  timing  statistics  may  be  used  by  human  factors  engi¬ 
neers  during  evaluation  and  fleet  operations  to  analyze  how  the  crew  used  AIDS. 
Figure  3-19  Illustrates  the  processing  flow  through  the  four  software  timing 
performance  monitoring  procedures. 

3. 3. 5. 4  System  Initialization 


The  System  Initialization  function  of  the  OSS  has  the  responsibility  of  ini¬ 
tiating  execution  of  the  entire  AIDS.  This  Initiation  may  occur  at  the 
beginning  of  a  mission  ("cold— start”),  during  a  mission  after  a  power  failure 
affecting  the  entire  AIDS  ("warm-start”),  or  during  a  mission  after  a  power  or 
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Fi-GURE  3-18  -  RECORD  DATA  and  SIGNAL  ERROR  processing 


FIGURE  3-19  -  Throughput  Perfonaance  Monitoring  Process 
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thermal  failure  affecting  only  an  AN/AYK-14  ("AN/AYK-14  recovery”).  In  response 
to  a  warm-start  or  AN/AYK-14  recovery,  System  Initialization  attempts  to  restore 
the  AIDS  to  the  configuration  which  existed  before  the  failure.  To  do  this, 
System  Initialization  uses  the  "System  Status  Table."  The  System  Status 
Table  at  any  point  In  time  describes  the  current  mission  mode,  the  aircraft 
status,  the  status  and  allocation  of  all  Che  AIDS  modules,  and  any  processing 
options  selected  by  the  crew.  The  table  Is  updated  by  all  the  data  processor 
programs.  That  Is,  whenever  a  program  senses  a  change  In  the  system  status. 
It  updates  the  Cable.  It  Is  Che  responsibility  of  the  Reconfiguration  process 
(see  Section  3. 3. 5. 5)  to  periodically  copy  the  table  to  the  mass  memory. 
Thus,  during  a  warm-start  or  AN/AYK-14  recovery.  System  Initialization  restores 
the  table  by  using  Che  copy  of  Che  cable  In  mass  memory. 

Initializing  AIDS  Includes  loading  Che  volatile  memories  of  all  the  AIDS 
hardware  modules.  The  System  Initialization  function  Itself  Is  loaded  Into  Che 
AN/AYK-14  by  the  Mbus  controller. 

Figure  3-20  Illustrates  Che  processing  flow  of  System  Initialization. 

3. 3. 5. 5  Reconf Iguratlon 

The  Reconfiguration  function  Is  responsible  for  maximizing  the  Information 
flow  to  the  crew  given  the  currently  operational  hardware.  Reconfiguration  per¬ 
forms  this  function  by  continuously  monitoring  the  health  of  all  the  AIDS  hard¬ 
ware  and  by  reconfiguring  the  system  in~. response  Co  hardware  failures.  Recon¬ 
figuration  Is  not  one  program;  rather,  failure  monitoring  and  failure  response 
for  a  given  hardware  module  are  performed  by  Che  particular  program  having  Che 
primary  Interface  Co  Che  module.  For  example,  the  InpuC/output  function  moni¬ 
tors  Che  Mbus,  Che  ODS  monitors  Che  displays,  and  DPICS  monitors  the  TCP's. 
The  reconfiguration  performed  by  the  various  programs  Is  coordinated  through 
Che  System  Status  Table,  which  Is  updated  by  each  program  when  it  performs  a 
reconfiguration  action. 

In  addition  to  Che  reconfiguration  procedures  In  Che  various  programs,  there 
is  a  central  "Reconfiguration  process”  which  Is  part  of  the  OSS.  This  process 
In  Che  OSS  Is  Che  system's  primary  HOL  process.  The  term  "Reconfiguration  func¬ 
tion”  refers  to  this  process  as  well  as  to  all  the  reconfiguration  procedures 
In  Che  various  application  programs.  The  Reconfiguration  process  Is  responsible 
for:  (1)  selecting  Che  appropriate  configuration  of  application  programs  In  the 
AN/AYK-14,  (2)  exchanging  status  Information  with  Che  Reconfiguration  processes 
in  the  other  MIDER,  and  (3)  periodically  copying  the  System  Status  Table  Into 
Che  System  Status  File. 

Figure  3-21  Illustrates  Che  processing  flow  In  the  Reconfiguration  process 
and  Che  generic  flow  In  a  reconfiguration  procedure. 

3. 3. 5. 6  overlay 

As  discussed  above,  there  will  be  several  configurations  of  Che  AN/AYK-14 
application  programs.  Configurations  will  vary  as  a  function  of  mission  mode 
and  also  as  a  function  of  operational  hardware.  For  example.  In  the  Preflight 
mode,  programs  are  required  for  processing  Che  checklists,  whereas  during  the 
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FIGURE  3-21  -  Reconfiguration  Processing 
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search  node  these  programs  could  be  replaced  with  the  ASW  mission  subsystem. 
In  the  AEW  AIDS,  when  both  data  processors  are  operational,  the  informa¬ 
tion  processing  will  be  distributed  between  them,  whereas  when  one  of  the  data 
processors  has  failed,  the  remaining  data  processor  must  be  reconfigured  to  per¬ 
form  only  the  most  critical  aspects  of  the  information  processing. 

The  Overlay  function  has  the  responsibility  of  loading  a  new  configuration 
of  application  programs.  The  AN/AYK-14  program  memory  will  be  divided  into 
two  segments.  One  segment  contains  the  OSS.  This  segment  is  loaded  into  the 
AN/AYK-14  by  the  Mbus  controller  and  is  never  replaced.  The  other  segment  con¬ 
tains  the  variable  configuration  of  application  programs.  For  simplicity,  the 
variable  segment  is  replaced  in  toto  by  the  Overlay  function.  Thus,  the  Overlay 
function  supports  only  a  single  level  overlay  structure.  The  Overlay  function 
is  invoked  by  the  Reconfiguration  process,  which  supplies  the  name  of  the  file 
containing  the  new  configuration  to  be  loaded. 

Figure  3-22  illustrates  the  processing  flow  of  the  Overlay  function. 
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FIGURE  3-22  -  Overlay  Processing 


65 


3. 3. 5. 7  Briefing  Information  Entry 


The  Briefing  Information  Entry  function  of  the  OSS  is  responsible  for  Ini¬ 
tializing  both  AIDS  and  the  external  avionics  subsystems  with  data  describing 
the  mission  to  be  performed  in  the  current  flight.  This  data  includes  map 
formats  for  the  geographic  areas  to  be  flown  over  during  the  mission,  supple¬ 
mental  tactical  information  corresponding  to  the  maps,  the  primary  and  alternate 
flight  plans,  and  preselected  communication  frequencies  and  codes. 

The  briefing  information  is  contained  on  a  cassette  tape  which  is  read  by 
the  Briefing  Information  Entry  Device  (BIED).  This  tape  is  prepared  by  the 
Mission  Preparation  System  which  formats  the  data  on  the  tape  into  records  which 
identify  to  the  OSS  the  system  which  should  receive  the  data.  Data  intended 
for  AIDS  is  stored  in  files  on  the  mass  memory  system.  Data  intended  for  one 
of  the  external  avionic  subsystems  is  transmitted  over  the  Kbus  to  the  subsys¬ 
tem.  Figure  3-23  illustrates  the  processing  flow  of  the  Briefing  Information 
Entry  function. 


FIGURE  3-23  -  Briefing  Information  Entry  Processing 
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^  3. 3. 5. 8  Switch  Processing 

The  Switch  Processing  function  within  the  AIDS  configuration  accepts  MCP 
and  ICP  coomands  from  the  crew  and  routes  these  commands  to  the  systems  onboard 
the  aircraft.  Crew  commands  are  input  to  the  flight  systems  by  a  sequence  of 
switch  depressions  through  the  Integrated  Control  Set  (ICS)  or  through  button 
depressions  on  the  flight  control  stick  acting  in  the  Hands-On'Throttle~and- 
Stlck  (HOTAS)  mode. 

AIDS  Switch  Processing  is  partitioned  into  two  functions:  the  Microproces¬ 
sor  Integrated  Control  Set  (MPICS)  firmware  and  the  Data  Processor  Integrated 
Control  Set  (DPICS)  software.  The  processing  performed  by  these  two  functions 
is  defined  by  the  AIDS  Command  Language  (ACOL).  This  language  is  used  to 
specify  the  ICS  programmable  switch  legends  (via  hierarchical  switch  sequences) 
and  their  interpretation  by  MPICS  and  DPICS.  The  ACOL  switch  specifications 
are  translated  by  the  AIDS  Command  Formatter  (ACF)  into  two  sets  of  tables. 
One  is  referenced  by  MPICS  while  the  other  is  referenced  by  DPICS  where  both 
functions  act  as  table-driven  interpreters. 

MPICS  controls  the  backlighting  of  all  switches,  changing  the  legends  of  the 
programmable-legend  switches,  verifying  the  legality  of  each  switch  depression, 
processing  numeric  entries,  reading  the  force  stick,  displaying  the  legends  of 
depressed  switches  on  the  scratchpad  display,  and  transmitting  commands  to 
DPICS.  Commands  do  not  necessarily  correspond  one-to-one  with  switch  depres¬ 
sions;  rather,  a  command  is  signaled  by  the.,  completion  of  a  sequence  of  switch 
depressions,  where  further  interpretation  requires  DPICS  processing. 

(  ' 

DPICS  accepts  switch  commands  from  MPICS  and  routes  them  to  their  intended 
destination.  A  command  destination  may  be  within  AIDS  (display  control)  or  ex¬ 
ternal  to  AIDS  (external  avionics  subsystem  control).  An  internal  AIDS  command 
is  routed  to  the  "command  input  queue"  of  the  appropriate  AIDS  function.  This 
queue  is  subsequently  read  by  the  AIDS  function  as  part  of  its  input  processing. 
DPICS  processing  of  an  external  AIDS  switch  command  results  in  the  output  of  a 
command  message  and  value  (via  the  OSS)  to  the  designated  external  avionics 
system. 

DPICS  processing  consists  of  three  functions:  switch  processing,  force 
stick  processing  (reference  Section  3. 3. 5. 9),  and  HOTAS  processing  (reference 
Section  3.3.3.10).  The  latter  two  functions  represent  specific  processing  re¬ 
sponses  to  force  stick  and  HOTAS  selections. 

Figure  3-24  Illustrates  the  Switch  Processing  function. 

3. 3. 3. 9  Force  Stick  Processing 

The  Force  Stick  function  is  activated  by  the  Switch  Processing  function  upon 
receipt  of  a  switch  command  specifying  a  force  stick  input  requirement.  Once 
activated,  the  Force  Stick  function  accepts  periodic  readings  (via  an  INPUT 
PERIODIC  MESSAGE  I/O  request)  from  the  ICS  force  stick  and  routes  these  readings 
to  the  destination  system  specified  by  the  Switch  Processing  function. 

t 
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In  addition  to  specifying  the  destination  system,  Switch  Processing  shall 
also  specify  the  associated  transformation  function  which  defines  how  to  trans¬ 
form  the  raw  force  stick  values  Into  destination-specific  values.  Each  trans¬ 
formation  function  is  a  piecewise  linear  function  with  at  most  five  discrete 
linear  segments.  Specific  Interpretations  of  the  "transformed"  force  stick 
values  Include,  for  example,  radio  volume  and  radio  tuning  frequency. 

The  Force  Stick  function  remains  active  until  terminated  by  Switch  Proces¬ 
sing  in  response  to  a  terminate  force  stick  switch  command.  Figure  3-25  illus¬ 
trates  the  Force  Stick  function's  processing. 

3.3.5.10  HOTAS  Processing 


The  Hand-on-Throttle-and-Stlck  (HOTAS)  Processing  function  is  responsible 
for  accepting,  interpreting,  and  routing  pilot  commands  arising  from  pilot  se¬ 
lection  of  the  buttons  on  the  throttle  and  the  flight  control  stick.  These 
commands  allow  pilot  selection  of  communication  channels  and  frequency  and 
also  provide  limited  menu-oriented  interaction  with  AIDS.  When  HOTAS  interac¬ 
tion  is  enabled,  AIDS  displays  a  menu  on  a  SAD,  and  via  stick  button  depres¬ 
sions  the  pilot  selects  desired  menu  items.  HOTAS  command  interpretation  and 
routing  are  performed  using  the  same  conventions  described  previously  for 
Switch  Processing. 

3.3.5.11  Voice  Recognition 

The  AIDS  Voice  Recognition  function  accepts,  interprets,  and  routes  com¬ 
mands  input  through  the  voice  recognizer.  The  voice  recognizer  is,  at  any  point 
in  the  mission,  configured  to  recognize  a  fixed  set  of  phrases  from  a  specific 
crewmember.  In  response  to  mission  mode  changes.  Voice  Recognition  requests 
the  mass  memory  to  transmit  to  the  voice  recognizer  the  voice  library  appropriate 
to  the  selected  mission  mode.  Thus,  for  the  takeoff  and  landing  modes,  the 
pilot's  voice  library  would  be  transmitted,  whereas  for  the  search  mode  either 
the  TACCO's  or  CICO's  voice  library  would  be  transmitted.  The  command  inputs 
received  from  the  voice  recognizer  are  coordinated  with  ICP-  and  HOTAS-generated 
commands  and  are  processed  using  the  conventions  described  above  for  ICP  Switch 
Processing. 

3.3.5.12  Graphics  Support 

The  Graphics  Support  function  of  the  OSS  is  responsible  for  displaying  in¬ 
formation  on  the  AIDS  displays.  In  response  to  function  calls,  Graphics  Support 
Initializes  the  processing  of  a  particular  format  on  a  particular  Symbol  Gener¬ 
ator  (SG)  and  subsequently  makes  changes  in  what  is  displayed  within  initialized 
formats.  An  SG  is  either  an  RSG,  the  HUD's  stroke  symbol  generator,  or  a  SAD 
symbol  generator.  If  graphics  devices  or  symbol  generators  malfunction,  the 
Graphics  Support  is  responsible  for  passing  this  information  to  the  currently 
loaded  ODS  programs.  A  large  group  of  Graphics  Support  procedures,  generl- 
cally  called  "put-procedures,"  will  be  described  as  a  unit  In  what  follows. 
The  other  Graphics  Support  procedures,  namely  CONFIGURE  SG,  ASSIGN  FORMAT  TO 
SG,  UPDATE  FORMAT,  and  STOP  SG  will  be  described  individually. 
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FIGURE  3-25  -  Force  Stick  Processing 


The  ODS  calls  CONFIGURE  SG  to  Initialize  the  device-dependent  processing 
parameters  of  a  symbol  generator.  These  parameters  Include  frame-rate,  Vbus 
output  channel  number,  and  aspect  ratio. 

ASSIGN  FORMAT  TO  SG  causes  a  particular  format  to  be  prepared  for  display 
on  one  of  the  symbol  generators.  The  SADI  program  for  the  format  Is  transmitted 
from  the  mass  memory  to  the  microprocessor  for  the  SG.  Internal  AIDS  software 
data  structures  are  also  Initialized.  This  initialization  Includes  retrieving 
format-specific  display  change  commands  from  the  mass  memory. 

The  Put  Procedures  are  used  by  the  ODS  software  to  change  a  format.  Formats 
are  created  prior  to  mission  time  by  the  action  of  the  GRADS  Picture  Compiler 
(Mlchener  80) .  The  GRADS  Picture  Compiler  compiles  a  high-level  picture  speci¬ 
fication  Into  SADI  Instructions.  The  picture  specification  describes  both  the 
visible  s3nid>ology  of  the  format  and  the  ways  In  which  this  symbology  may  change. 
Each  aspect  of  a  format  which  may  change  Is  identified  uniquely  by  a  "rapid 
change”  name.  Put  Procedures  are  Che  means  by  which  Che  ODS  makes  specific 
changes  to  Che  visible  symbology  of  a  format.  There  are  Put  Procedures  to  change 
Che  following  aspects  of  a  format,  Che  terminology  Is  defined  In  (Mlchener  80): 

o  X  coordinate  or  Y  coordinate  of  any  position  (PUT  COORD). 

o  X  coordinate  and  Y  coordinate  of  any  position  (PUT  PT). 

o  Visibility  of  part  of  a  format  (PUT  ATVAL). 

o  Blinking  of  part  of  a  format  (PUT  ATVAL). 

o  Intensity  of  part  of  a  format  (PUT  ATVAL). 

o  Translation,  rotation,  or  scaling  of  part  of  a  format  (PUT  PT, 

PUT  ANGLE,  PUT  SCALE). 

o  Characters  in  or  length  of  a  text  string  (PUT  CHARS,  PUT  TEXTLENGTH) . 
o  Radius  of  a  circle  (PUT  COORD). 

o  Display-specific  parameters  of  a  format  (e.g.,  PUT  SKYGROUND). 

Format  changes  specified  by  calls  to  Put  Procedures  do  not  result  Imme¬ 
diately  in  visible  changes  to  the  displayed  symbology  because  these  format 
changes  are  buffered  by  the  graphics  support.  After  an  ASSIGN  FORMAT  TO  SG  In¬ 
vocation,  Che  calling  ODS  program  would  typically  call  Put  Procedures  so  that 
the  very  first  display  of  Che  newly  loaded  format  is  in  accord  with  current 
aircraft  or  mission  status. 

UPDATE  FORMAT  is  a  signal  from  the  ODS  programs  to  Che  Graphics  Support 
that  It  is  time  for  the  accumulated  changes  for  a  given  format  to  be  sent  to 
the  SG. 
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The  UPDATE  FORMAT  call  also  starts  an  SG  processing  Its  newly  loaded 
format.  For  example,  the  ODS  program  controlling  a  format  which  changes  at 
20  Hz  would,  every  20th  of  a  second,  call  various  Put  Procedures  and  then 
call  UPDATE  FORMAT  to  send  all  the  changes  to  the  SG  for  the  format.  If,  in 
addition,  parts  of  the  format  change  only  at  5  Hz,  then  every  fourth  time  the 
ODS  program  executes,  it  would  call  Put  Procedures  for  those  parts  of  the  format 

STOP  SG  causes  a  symbol  generator  to  cease  processing  its  current  format  and 
to  remove  visible  information  previously  generated  for  that  format  from  any  dis¬ 
plays  on  which  it  appears.  Thus,  an  RSG  would  be  told  both  to  cease  processing 
the  format  and  to  cease  transmitting  the  raster  output  buffer  over  the  Vbus  to 
the  AIDS  displays. 

Figures  3-26  and  3-27  Illustrate  the  functional  processing  of  the  Graphics 
Support  procedures. 

3.3.5.13  Voice  Synthesis 

The  AIDS  Voice  Synthesis  function  receives  requests  from  any  of  the  applica¬ 
tion  functions  to  output  one  of  a  predefined  set  of  voice  messages.  In  response 
Voice  Synthesis  formats  and  outputs  these  requests  to  the  voice  synthesizer. 
Voice  Synthesis  is  also  responsible  for  setting  the  voice  characteristic  par¬ 
ameters  of  the  voice  synthesizer. 


3.3.5.14  Video  Input 

The  AIDS  Video  Input  function  is  responsible  for  communication  with  the 
V/STOL  video  sensors,  assigning  Vbus  channels  to  these  sensors;  assigning  syn¬ 
chronization  signals  to  these  sensors,  if  required,  and  routing  the  video  input 
to  the  appropriate  RSG  for  mixing  with  AIDS-generated  symbology.  All  of  the 
above  functions  are  performed  in  response  to  requests  for  video  input  from  the 
application  programs. 


3.3.5.15  Flight  Data  Display 

The  Flight  Data  Display  function  is  responsible  for  performing  all  process¬ 
ing  associated  with  flight  symbology  display.  The  processing  Includes  input 
data  conversion  and  verification,  sensor  failure/recovery,  and  symbol  activa¬ 
tion  and  positioning.  Input  sources  are  NAV/JTIDS,  DFICS,  and  the  Helmet 
Position  Sensor.  The  Flight  Data  Display  function  controls  the  display  of 
symbology  on  the  HUD,  HMD,  VSD,  and  HSD. 

Flight  Data  Display  periodically  samples  the  flight  parameter  buffers  input 
from  NAV  and  JTIDS.  The  maintenance  of  these  buffers  is  performed  by  the  OSS. 
Those  flight  parameters  which  have  changed  since  a  previous  update  period  are 
verified  against  their  legal  value  ranges.  A  parameter  falling  the  verification 
process  has  its  associated  sensor  status  indicator  reclassified  as  "failed”;  an 
alternative  sensor  will  be  activated  if  such  a  backup  currently  exists. 
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FIGURE  3-26  -  Symbol  Generator  Control  Processing 
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FIGURE  3-27  -  Format  Update  Processing 


Display  update  processing  Is  performed  by  the  Flight  Data  Display  function 
by  examining  display  format  and  status  change  Indicators  within  the  flight  dis¬ 
play  data  base.  Display  processing  Includes  format  changes  In  response  to  mis¬ 
sion  mode  changes,  changes  In  symbol  visibility  and  presentation  (e.g.,  change 
In  display  format,  map  position,  or  device  destination),  and  changes  In  display 
device's  status  (active/inactive) .  Update  processing  of  any  Individual  display 
is  dependent  upon  the  current  format.  For  example,  symbol  visibility  process¬ 
ing  is  not  required  if  a  symbol  is  currently  not  "active.”  Specific  display 
formats  are  presented  in  Section  3.4.15. 

Figure  ?-28  Illustrates  the  Flight  Data  function's  processing.  This  pro¬ 
cessing  is  performed  at  both  60  Hz  and  20  Hz  for  different  flight  parameters. 

3.3.5.16  Equipment  Monitoring 

The  Equipment  Monitoring  function  is  responsible  for  providing  the  crew¬ 
members  with  system  status  Information.  This  Information  Is  displayed  on  the 
AIDS  SAD.  The  status  Information  is  displayed  in  either  a  checklist  or  a 
system  monitoring  mode.  Equipment  Monitoring  Includes  conversion  of  periodic 
sensor  samples  to  internal  AIDS  representations,  modification  of  the  advisory 
display  presentations,  and  crewmember  notification  (via  the  SAD)  of  sensor 
failure  occurrences.  Periodic  sensor  samples  and  asynchronous  failure  notifi¬ 
cations  are  Input  to  this  function  from  the  ULAIDS  and  lEIS  while  asynchronous 
display  control  commands  are  Input  from  DPICS. 

The  ULAIDS  and  lEIS  transmit  periodically  to  Equipment  Monitoring  those 
sensor  parameters  currently  being  presented  on  the  SADs.  Equipment  Monitoring 
converts  the  sensor  value  contents  to  their  Internal  AIDS  representations  and 
subsequently  uses  these  converted  values  to  update  the  appropriate  sensor 
value  fields  on  the  SADs.  This  periodic  process  continues  until  a  new  format 
representation  Is  to  be  presented  on  a  SAD  in  response  to  a  DPICS  format  change 
command. 

In  response  to  a  sensor  failure  occurrence,  the  ULAIDS  and  lEIS  transmit 
asynchronously  to  the  Equipment  Monitoring  function  a  failure  notification 
defining  the  particular  sensor  and  Its  present  value.  In  response.  Equipment 
Monitoring  places  the  corresponding  failure  message  Into  a  failure  queue.  All 
failure  messages  are  placed  In  this  queue;  after  the  currently  displayed  fail¬ 
ure  message  Is  explicitly  acknowledged  by  the  crewmember,  the  oldest  failure 
message  Is  removed  from  the  queue  and  displayed. 

Processing  of  DPICS  Inputs  will  be  dependent  upon  the  type  of  format  cur¬ 
rently  being  presented  on  the  SAD.  For  checklist  formats,  DPICS  Input  responses 
consist  of  page  advancement,  cursor  advancement,  and  prompt  Inputs.  The  sys¬ 
tem  monitoring  formats  are  hierarchically  structured  where  higher-level  formats 
contain  summary  status  information  and  lower-level  formats  contain  detailed  in¬ 
formation.  DPICS  Input  commands  allow  for  selection  of  any  level  presentation. 

For  either  format  presentation,  DPICS  Inputs  responses  allow  for  failure  mes¬ 
sage  acknowledgement.  This  acknowledgement  response  results  In  the  presentation 
of  the  appropriate  sensor  failure  information  as  well  as  the  display  of  the  next 
failure  message.  If  one  exists. 
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FIGURE  3-28  -  Flight  Data  Proceaalng 
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Figure  3-29  illustrates  Equipment  Monitoring  processing.  This  processing 
is  performed  at  a  5-Hz  rate  as  well  as  a83mchronously  in  response  to  a  sensor 
failure. 


3.3.5.17  Communications  Data  Display 

The  Communications  Data  Display  function  is  responsible  for  providing  the 
pilot  with  communication  equipment  information.  This  information  is  displayed 
on  the  AIDS  SADs.  The  inputs  to  this  function  are  provided  by  the  COMM  exter¬ 
nal  avionics  subsystem. 


3.3.5.18  ASW  Display 

The  AIDS  ASW  Display  function  is  responsible  for  the  three  displays  (TD, 

ADU  and  SAD)  at  the  two  ASW  mission  officer  stations  (TACCO  and  SEMSO).  On 
the  TD,  the  ASW  Display  function  displays  a  geographic  format  indicating 
sonobuoys,  targets,  and  waypoints.  On  the  ADU  Che  ASW  Display  function  dis¬ 
plays  formatted  acoustic  data.  The  ASW  Display  function  commands  Che  signal 
processor  to  format  the  acoustic  data  according  to  Che  mission  officer  selected 
format.  On  Che  SAD,  the  ASW  Display  function  presents  an  alphanumeric  annota¬ 
tion  of  both  Che  current  TD  and  ADU  formats. 


3.3.5.19  AEW  Display  _ 

The  AIDS  AEW  Display  function  is  responsible  for  the  two  displays  (TD  and 
SAD)  at  each  of  the  three  AEW  miaslon  officer  stations  (CICO,  ACOl,  and  AC02). 
On  the  TD,  the  AEW  Display  function  displays  a  geographic  format  Illustrating 
the  tactical  environment.  On  the  SAD,  the  AEW  Display  function  displays  an 
alphanumeric  annotation  of  the  TD's  tactical  environment  format. 


3.4  DETAILED  FUNCTIONAL  REQUIREMENTS 

This  section  contains  the  detailed  requirements  of  the  19  AIDS  software 
functions  described  above.  Each  function  is  specified  in  terms  of  its  Inputs, 
processing,  outputs,  and  special  requirements.  For  all  of  the  functlors,  sev¬ 
eral  special  requirements  for  debugging  and  testing  apply.  These  special  re¬ 
quirements  are  specified  below. 

Each  function  shall  optionally  verify  and  record  all  of  its  Inputs.  Each 
function  shall  Include  timing  Information  in  its  data  recording  output.  Also, 
each  function  shall  utilize  the  performance  monitoring  facilities  of  the  OSS. 
Performance  monitoring  Information  shall  be  used  to  optimize  execution  perform¬ 
ance  of  the  AIDE. 

It  shall  be  possible  to  exclude  from  a  function  the  code  required  for  data 
verification,  data  recording,  and  performance  monitoring.  It  shall  also  be 
possible  to  enable  and  disable  execution  of  this  code. 
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FIGURE  3-29  -  Equipment  Monitoring  Processing 
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When  a  function  diagnoses  either  a  hardware  error  for  which  no  corrective 
action  Is  possible  or  any  software  error,  the  function  shall  utilize  the  OSS 
signal-error  mechanism.  After  signaling  the  error,  the  function  shall  either 
attempt  recovery  action  or  terminate. 

In  addition  to  these  special  requirements,  which  are  applicable  to  all  the 
AIDS  functions,  several  of  the  AIDS  functions  have  a  requirement  to  perform 
hardware  failure  monitoring  and  recovery.  Each  function  which  Is  responsible 
for  controlling  a  given  hardware  module  Is  also  responsible  for  the  Reconfigura¬ 
tion  processing  associated  with  that  module.  This  Reconfiguration  processing 
Is  not  discussed  in  the  processing  subsection  for  each  function.  Instead,  the 
discussion  of  the  Reconfiguration  processing  for  all  the  functions  Is  central¬ 
ized  In  Section  3. 4. 5. 2,  ”Reconf Iguratlon  Processing." 

The  19  functions  are  described  In  this  section  according  to  the  order  used 
In  Section  3.3.5.  In  the  description  of  each  function's  Inputs  and  outputs, 
the  following  conventions  are  used.  If  Inputs  or  outputs  are  supplied  as  pro¬ 
cedure  call  parameters,  they  are  identified  as  In  the  following  example  of 
Inputs  to  the  Mbus  I/O  function: 

STOP  PERIODIC  INPUT  Parameters 
Source  Identification 
Message  Code 

Alternatively,  If  the  Inputs  are  suppllejl  as  a  table  In  memory,  they  are 
Identified  as  In  the  following  example  ^lustratlng  the  destination  command 
table  supplied  to  OSS  by  the  Mbus  controller: 

Destination  Command  Fields 
Source  Identification 
Message  Code 
Number  of  Words 


3.4.1  Input/Output  (I/O)  Requirements 


The  I/O  function  of  the  OSS  Is  responsible  for  translating  application  pro¬ 
gram  requests  for  input  and  output  into  commands  conforming  to  the  Mbus  protocol. 
The  Mbus  protocol  Is  described  briefly  In  Section  3. 3. 1.2  of  this  specification 
and  In  detail  In  the  "AIDS  System  Specification  for  Advanced  Development  Model” 
(GE79a) . 


3. 4. 1.1  I/O  Inputs 


Input 


Source 


Frequency 


OUTPUT  MESSAGE  Parameters  Application  Aperiodic 

Buffer  Address  Program 

Number  of  Words 
Destination  Identification 
Message  Code 
Priority  Indication 
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Input 


Source 


INPUT  SINGLE  MESSAGE  Parameters 
Buffer  Address 
Number  of  Words 
Source  Identification 
Message  Code 

INPUT  PERIODIC  MESSAGES 
Paramete  rs : 

Buffer  Address 
Number  of  Words 
Source  Identification 
Message  Code 

STOP  PERIODIC  INPUT 
Parameters 

Source  Identification 
Message  Code 

Source  Command  Resource 


Application 

Program 


Application 

Program 


Application 

Program 


SDEX/M 


Synchronization  Signal 


Mbus  <vla 
SDEX/M) 


Signal  Code  Values  _  Hbus 

Souree**Command-Read 
Souree-Buffer^Emptled 
Des tlnat lon-Command-Wrl tten 
Destlnatlon-Buf  fer-Fllled 
Completion  Identifier 


Frequency 

Aperiodic 


Aperiodic 


Aperiodic 


Aperiodic 

Aperiodic 


Destination  Command  Fields 
Source  Identification 
Message  Code 
Number  of  Words 

3. 4. 1.2  I/O  Processing 

For  output  operations,  the  OSS  I/O  processing  begins  with  an  application  pro¬ 
gram  OUTPUT  HESSACT  request.  In  response,  the  OSS  shall  transfer  the  request 
parameters  (buffer  address,  number  of  words,  destination  Identification,  message 
code,  and  priority  Indication)  Into  the  source  conuoand.  However,  because  multi¬ 
ple  processes  will  be  using  the  source  command,  the  OSS  shall  first  request 
write  access  to  the  source  command.  Access  shall  be  controlled  via  an  HOL  re¬ 
source  variable.  After  completing  the  source  command,  the  OSS  shall  Initiate 
the  write  operation  by  Issuing  an  Interrupt  to  the  Mbus.  The  Interrupt  shall 
be  emitted  via  the  AN/ATK-lA's  Discrete  Interface  Module  programmable  Interrupt 
facility.  The  Discrete  Interface  Module  I/O  program  shall  be  Initiated  using 
the  SDEX/M  Executive  I/O  Coomand  ESR.  The  OSS  shall  Identify  the  synchroniza¬ 
tion  signal  as  the  source  command  ready  signal  by  storing  the  value  ”1"  Into 
the  source  command  ready  word.  After  Initiating  this  I/O  Program,  the  OSS  shall 
wait  for  the  responding  synchronization  signal  from  the  Mbus. 
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When  the  Mbus  has  read  the  source  command.  It  Interrupts  the  data  processor 
I  using  the  Discrete  Interface  Module.  Upon  receiving  the  Interrupt,  the  OSS 

shall  read  the  Mhus  Interrupt  code  ring  buffer  to  determine  to  which  Mbus  signal 
the  Interrupt  corresponds. 

If  the  signal  was  for  source-command-read,  the  signal  Is  In  response  to  the 
source-command-written  signal  generated  by  the  data  processor.  (The  processing 
for  the  three  other  possible  signal  codes  Is  discussed  below. )  In  response  to 
the  source-command-read  signal,  the  OSS  shall  release  the  source  command  re¬ 
source  and  then  await  a  signal  from  the  Mbus  chat  Che  message  transmission  has 
been  completed.  When  this  signal  occurs,  the  OSS  returns  control  to  the  appli¬ 
cation  program. 

For  Input  operations,  OSS  I/O  processing  begins  with  receipt  from  the  Mbus 
of  Che  destlnaClon-command-wrlcten  signal.  In  response,  the  OSS  shall  deter¬ 
mine  the  Input  buffer  which  corresponds  to  Che  message  source  and  code.  This 
correspondence  Is  determined  by  searching  the  table  which  contains  the  out¬ 
standing  Input  message  reqtiests  from  application  programs.  Entries  are  stored 
In  this  cable  In  response  to  both  INPUT  SINGLE  MESSAGE  and  INPUT  PERIODIC 
MESSAGES  requests.  If  an  entry  Is  not  found  for  the  particular  source  and 
code,  Che  OSS  shall  signal  an  error  and  shall  accept  the  Input  In  Its  own 
buffer  space.  (After  receiving  Che  Input,  the  OSS  shall  Chen  use  the  data 
recording  facility  to  log  Che  contents  of  the  unexpected  Input  message.) 

Assuming  the  message  Is  expected,  tt^  OSS  shall  store  the  corresponding 
Input  buffer  address  and  completion  identifier  Into  the  destination  command. 

/  The  OSS  shall  then  signal  the  Mbus  using  the  Discrete  Interface  Module.  The 

V  .  OSS  shall  Identify  the  Interrupt  as  the  destlnatlon-command-ready  signal  by 
storing  the  value  "1"  into  the  destination  command  ready  word. 

When  Che  Mbus  signals  completion  of  the  message  Input,  the  OSS  response 
depends  on  the  corresponding  Input  message  request.  If  the  request  was  INPUT 
SINGLE  tCSSAGE,  the  OSS  shall  return  to  the  application  program  with  the  number 
of  words  as  an  output  parameter.  If  the  request  was  INPUT  PERIODIC  MESSAGES, 
the  OSS  shall  Increment  the  message  sequence  counter  and  store  the  number  of 
words  Input.  The  counter  and  number  of  words  will,  by  convention,  be  the  first 
two  words  In  Che  Input  buffers.  The  OSS  shall  request  the  Mbus  to  store  the 
Input  message  beginning  two  words  beyond  the  beginning  of  the  appllcatlon- 
program-supplled  address. 

As  Inferred  above,  the  OSS  oiust  receive  an  Input  message  request  prior  to 
the  arrival  of  Che  corresponding  Input  message.  Both  Che  INPUT  SINGLE  MESSAGE 
and  INPUT  PERIODIC  MESSAGES  requests  Include  as  parameters  Che  message  source 
and  code,  Che  Input  buffer  address,  and  maximum  number  of  words.  When  the  cor¬ 
responding  message  arrives,  If  Its  length  Is  greater  than  the  applicatlon- 
program-speclfled  maximum,  the  OSS  shall  treat  the  message  as  an  unexpected  mes¬ 
sage. 


After  the  message  corresponding  to  INPUT  SINGLE  MESSAGE  request  has  been 
received,  the  OSS  shall  remove  the  message  request  from  the  unexpected  message 
table  before  returning  to  the  requester. 
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3. 4. 1.3  I/O  Outputs 
Output 

Synchronization  Signal 

Signal  Code  Values 

Source-Connand-Wrltten 

Des tlnat lon-Command-Coaple ted 

Source  Connand  Fields 

Destination  Identification 
Message  Code 
Priority  Indication 
Buffer  Address 
Number  of  Words 
Source  Identification 
Completion  Identifier 

Destination  Command  Fields 
Buffer  Address 
Completion  Identifier 

Source  Command  Resource 

Input  Sequence  Number 


Number  of  Words 


Destination  Frequency 
Mbus  (via  SDEX/M)  Aperiodic 
Mbus 

Mbus  Aperiodic 


Mbus 

Aperiodic 

SDEX/M 

Aperiodic 

Application 

Aperiodic 

Program 

Application 

Aperiodic 

Program 

3 . 4 . 1 . 4  I/O  Special  Requirements 

1.  The  source  command,  the  destination  command,  and  the  signal  Identifica¬ 
tion  queue  shall  be  allocated  at  virtual  locations,  TBD,  TBD,  and  TBD,  respec¬ 
tively  In  the  data  processor's  memory. 

2.  All  Input  and  output  buffers  shall  be  allocated  within  the  first  16R 
words  of  the  data  processor's  virtual  memory. 

3.  The  data  processor  shall  respond  to  the  destlnatlon-command-wrltten 
signal  within  1  msec. 

4.  The  I/O  function  shall  be  reentrant. 

3.4.2  File  System  Requirements 

The  File  System  function  of  the  OSS  is  responsible  for  translating  applica¬ 
tion  program  requests  to  create,  write,  and  read  files  Into  requests  conforming 
to  the  mass  memory  system  interface.  The  File  System  function  Is  also  respon¬ 
sible  for  monitoring  the  health  of  the  mass  memory  system  and  utilizing  an 


y.  alternate  mass  memory  system  la  respoase  to  mass  memory  failure.  The  AIDS  mass 
4  memory  system  Is  described  briefly  In  Section  3. 3. 1.6  and  In  detail  In  the  "Mass 
Memory  System  Advanced  Development  Description"  (GE  79a). 


3. 4. 2.1  File  System  Inputs 


( 


Input 

CREATE  FILE  Parameters 
File  Length 

WRITE  FIL^  Parameters 
File  Name 
Buffer  Address 
Buffer  Length 
Destination  Identification 

READ  FILE  Parameters 
File  Name 
Buffer  Addre^fs 
Buffer  Length 

Destination  Identification 


Source 


Application 

Program 

Application 

Program 


Application 

Program 


LOG  Parameters 

Buffer  Address 
Buffer  Length 

File  Directory 


Application 
_ Program 


System  Generation 
(via  Mass  Memory) 


3. 4. 2. 2  File  System  Processing 


Frequency 

Aperiodic 


Aperiodic 


Aperiodic 


Aperiodic 


Aperiodic 


File  System  processing  may  be  described  In  terms  of  Its  respoase  to  the 
four  file  access  requests.  In  response  to  a  CREATF  FILE  request,  the  OSS  shall: 
(1)  allocate  the  next  available  entry  In  the  file  directory;  (2)  enter  Into  this 
entry  the  file's  length  as  specified  In  the  request;  (3)  allocate  the  requested 
number  of  wordit  from  the  unused  area  of  mass  memory;  and  (4)  return  as  an  output 
parameter  the  Index  of  the  allocated  file  directory  entry. 


For  a  WRITE  FILE  request,  the  OSS  shall  Issue  a  write  request  to  the  mass 
memory  system  using  the  data  addressed  by  the  buffer  address  parameter  In  the 
WRITE  FILE  request  and  using  as  the  mass  memory  starting  address  the  value  con¬ 
tained  In  the  directory  entry  for  the  Input  file  name.  The  file  processing  func¬ 
tion  shall  return  to  the  user  after  completion  of  the  write  operation. 


For  a  READ  FILE  request,  the  OSS  shall  Issue  a  read  request  to  the  mass 
memory  system  where  the  mass  memory  words  to  be  read  are  those  specified  In  the 
file  directory  entry  selected  by  the  Input  file  name.  If  the  destination  Iden¬ 
tification  Is  the  data  processor  Itself,  the  file  data  Is  read  Into  the  memory 
Identified  by  the  Input  buffer  address.  (If  the  file  length  Is  greater  than 
the  input  buffer  length,  the  OSS  shall  signal  an  error.)  If  the  destination 
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address  Is  not  the  data  processor,  the  OSS  shall  request  the  mass  memory  to 
transmit  the  file  contents  to  the  specified  destination.  In  either  case,  the 

OSS  shall  return  to  Che  requester  after  Che  file  concents  have  arrived  at  the 

specified  destination. 

On  a  LOG  request,  the  OSS  shall  Issue  a  request  to  Che  mass  memory  to  write 

Che  data  specified  In  the  LOG  request.  The  data  shall  be  written  In  mass  memory 

at  the  end  of  Che  LOG  file.  The  OSS  shall  return  to  the  user  after  completion 
of  write  request. 

3. 4. 2. 3  File  System  Outputs 


Output 

Destination 

Frequency 

Mass  Memory  Write  Parameters 

TBD 

Mass  Memory  (via  Input/ 
Output  Function) 

Aperiodic 

Mass  Memory  Read  Parameters 

TBD 

Mass  Memory  (via  Input/ 
Output  Function) 

Aperiodic 

File  Contents 

Application  Program 
and  Mass  Memory 

System 

Aperiodic 

3. 4. 2. 4  File  System  Special  Requirements 


None. 


3.4.3  Performance  Monitoring  Requirements 


The  Performance  Monitoring  function  of  the  OSS  has  the  dual  role  of:  (1) 
monitoring  the  performance  of  the  AIDS  software  In  terms  of  Its  execution 
speed,  and  (2)  providing  general-purpose  data  recording  and  error  notification 
services.  The  Performance  Monitoring  function  does  not  monitor  the  status  of 
the  AIDS  hardware;  this  function  Is  performed  by  the  Reconfiguration  function. 
However,  the  Performance  Monitoring  data  recording  and  error  notification 
services  are  used  by  Che  Reconfiguration  function  to  both  record  hardware 
failures  and  notify  the  crew  of  hardware  failures. 


3.4. 3.1  Performance  Monitoring  Inputs 


Input 


Source 


RECORD  DATA  Parameters:  Application 

Buffer  Address  Program 

Buffer  Length 


SIGNAL  ERROR  Parameters  Application 

Error  Message  Program 

Error  Code :  Warning , 

Caution,  or  Advisory 
Act Ion 


Frequency 

Aperiodic 


Aperiodic 
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Input 

Source 

Frequency 

TIMING  SEQUENCE  Parameters 
Timing  Identifier 

Application 

Program 

Aperiodic 

BEGIN  TIMx.  J  Parameters 

Timing  Identifier 

Application 

Program 

Aperiodic 

END  TIMING  Parameters 

Timing  Identifier 

Application 

Program 

Aperiodic 

RECORD  TIMING 

Application 

Program 

Aperiodic 

3. 4. 3. 2  Performance  Monitoring  Processing 

In  response  to  a  RECORD  DATA  request,  the  OSS  shall  construct  a  data  re¬ 
cording  message  conforming  to  the  Interface  specification  between  the  AIDS 
OSS  and  the  AIDS  Data  Reduction  Systems.  This  specification  requires  each 
message  to  contain  time  of  generation.  Identification  of  the  message  originator, 
the  message  type,  the  length  of  the  message,  and  the  message  Itself.  After 
constructing  the  message,  the  OSS  shall  log  the  message  using  the  LOG  procedure 
of  the  File  System. 

In  response  to  a  SIGNAL  ERROR  requeait,  the  OSS  shall  respond  according  to 
the  system  execution  mode  and  the  action  requested  by  the  user.  The  action 
parameter  may  be  either  terminate  or  continue  processing.  The  execution  mode 
may  be  either  operational  or  debugging.  In  all  cases,  the  error  message  shall 
be  displayed  to  the  appropriate  crewmember  according  to  the  error  code  (Warning, 
Caution,  or  Advisory).  Additionally,  the  error  occurrence  shall  be  logged  using 
the  RECORD  DATA  function.  If  the  requested  action  Is  continue  processing,  the 
OSS  shall  return  to  the  user,  regardless  of  the  system  execution  mode.  If  the 
requested  action  is  terminate  processing  and  the  execution  mode  Is  operational, 
the  OSS  shall  terminate  the  process  Issuing  the  request.  Finally,  If  the  re¬ 
quested  action  Is  terminate  processing  ard  the  execution  mode  Is  debugging,  the 
OSS  shall  Invoke  the  debugger  to  allow  the  programmer  to  Investigate  the  error 
condition. 

In  response  to  a  TIMING  SEQUENCE  request,  the  OSS  shall  allocate  and  Initial¬ 
ize  an  entry  In  Its  timing  cable.  Henceforth,  the  references  to  the  timing  se¬ 
quence  Identified  by  the  timing  Identifier  Input  parameter  shall  refer  to  this 
entry.  In  response  to  a  BEGIN  TIMING  request,  the  OSS  shall  begin  accumulating 
the  amount  of  CPU  time  spent  executing  the  process  which  Issued  the  BEGIN  TIMING 
request.  This  accumulation  shall  continue  until  an  END  TIMING  request  with  the 
same  timing  Identifier  is  received  by  the  OSS.  At  this  time,  the  OSS  shall  up¬ 
date  the  entry  associated  with  the  timing  Identifier.  The  updated  entry  will 
contain  the  number  of  times  the  sequence  has  been  timed,  and  the  maximum  time 
and  average  time  spent  executing  the  sequence.  Finally,  In  response  to  a 
RECORD  TIMING  request,  the  OSS  shall  call  the  RECORD  DATA  function  to  log  the 
entire  timing  table. 
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3. 4. 3. 3  Performance  Monitoring  Outputs 

Output  Destination  Frequency 

Error  Messages  Pilot  (via  ODS)  Aperiodic 

Data  Log  Messages  Log  (via  File  System)  Aperiodic 

Application  Program  Data 
Error  Data 
Timing  Data 

3.4.4  System  Initialization  Requirements 

The  System  Initialization  function  of  the  OSS  Is  responsible  for  Initiating 
the  execution  of  first  the  AIDS  data  processor  and  then  the  entire  AIDS.  Ini¬ 
tiation  occurs  In  one  of  three  modes:  cold-start,  warm-start,  and  AN/AYK-14 
recovery. 


3. 4. 4.1  System  Initialization  Inputs 


Input 

AN/AYK-14  Program  Load 


Source 

Mass  Memory  (via  Mbus 
Controller) 


Frequency 

Once 


Initialization  Code  Values 
Cold-Start 
Warm-Start 
AN/AYK-14  Recovery 


Mbus  Controller 
Mbus  Controller 
OSS  Reconfiguration 


Once 


AN/AYK-14  Hardware 
Status 


In-Flight  Performance  Once 

Monitoring  (IFPM) 


System  Status  Table 


Mass  Memory 


Once 


3. 4. 4. 2  System  Initialization  •Processing 

The  data  processor  execution  will  be  Initiated  either  by  the  Mbus  controller 
or  by  the  AN/AYK-14  restart  logic.  Initiation  by  the  Mbus  controller  will  occur 
either  after  the  pilot  first  applies  power  to  the  AIDS  (cold-start)  or  after 
the  recovery  from  power  failure  recognized  by  the  Mbus  (warm-start).  Initia¬ 
tion  by  the  AN/AYK-14  restart  logic  will  occur  following  a  power  or  thermal 
failure  which  affected  only  the  AN/AYK-14  (AN/AYK-14  recovery).  The  data 
processor  shall  determine  the  Initiation  source  by  Interrogating  the  initiation 
code  stored  In  the  AN/AYK-14  memory  In  response  to  the  AN/AYK-14  power  or 
thermal  tolerance  Interrupt.  The  Mbus  controller  will  have  stored  either  the 
cold-start  or  warm-start  code  In  the  word  If  It  Is  responsible  for  AN/AYK-14 
execution  Initiation. 
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Following  initiation,  the  OSS  shall  invoke  the  IFPM  procedure  to  determine 
the  AN/AYK-14  hardware  status*  If  the  hardware  is  not  sufficiently  functional 
to  complete  system  initialization,  the  OSS  shall  Inform  the  Mbus  controller  and 
shall  then  terminate.  Otherwise,  the  OSS  shall  continue  system  initialization 
by  Initializing  the  System  Status  Table. 

The  System  Status  Table  contains,  at  any  time  during  the  mission,  the  in¬ 
formation  to  restore  the  system  In  event  of  a  power  interruption.  The  table 
Includes  the  status  of  all  the  AIDS  hardware  modules,  the  current  mission  mode, 
and  the  values  of  any  crew-controlled  system  parameters  such  as  communication 
frequencies  and  format  selection.  If  the  OSS  Is  Initializing  from  a  cold-start. 
It  will  construct  this  table  according  to  defaults  established  at  systaa  genera¬ 
tion.  Examples  of  these  defaults  are  that  all  hardware  Is  operational,  the 
mission  mode  Is  preflight,  and  there  are  no  selected  communication  frequencies. 

If  the  OSS  Is  Initializing  from  either  a  warm-start  or  an  AN/AYK-14  recovery, 
the  System  Status  Table  shall  be  Initialized  by'  copying  from  the  mass  memory 
system  the  last  version  of  this  table  which  was  written  into  the  System  Status 
File. 

Once  the  System  Status  Table  has  been  initialized,  the  OSS  shall  then  Ini¬ 
tialize  the  rest  of  the  AIDS  according  to  the  System  Status  Table  and  the 
initialization  code.  First,  the  OSS  shall  transmit  to  the  Mbus  controller  the 
message  routing  table.  The  routing  paths  contained  In  the  table  shall  be  deter¬ 
mined  according  to  the  System  Status  Table.  The  OSS  shall  begin  the  system 
processing  by  activating  the  OSS  Reconfiguration  Process.  Following  this  acti¬ 
vation,  system  Initialization  terminates. 

Upon  activation  on  a  cold-start,  the  Reconfiguration  Process  shall  first 
load  DPICS  and  MPICS  with  the  tables  which  describe  the  Interpretation  of  the 
programmable  switches.  Several  versions  of  these  tables  will  be  stored  In  the 
mass  memory,  where  each  version  applies  o  a  particular  ICS  usage  (e.g..  Pilot 
ICS,  TACCO  ICS,  and  CICO  ICS).  The  Rf  . .\£lguratlon  Process  shall  deterMne 
which  version  to  load  by  referencing  the  System  Status  Table.  Also  on  a  cold- 
start,  after  loading  the  MPICS  and  DPICS  tables,  the  Reconfiguration  Process 
shall  request  the  Overlay  function  to  load  the  data  processor  memory  with  the 
application  programs. 

After  loading  the  application  programs  and  the  DPICS  and  MPICS  tables,  the 
Reconfiguration  Process  shall  activate  MPICS  and  DPICS.  Further  system  pro¬ 
cessing  shall  then  be  performed  In  response  to  crew  commands  communicated  through 
these  processes. 

3. 4. 4. 4  System  Initialization  Outputs 


Output 

Destination 

Frequency 

AN/AYK-14  Hardware  Failure 

Mbus  Controller 

Once 

System  Status 

System  Status  Table 

Once 

Mbus  Routing  Table 

Mbus  Controller 

Once 

Process  Activation 

Reconfiguration 

Once 
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3. 4. 4. 5  System  Initialization  Special  Requirements 
None. 

3.4.5  Reconfiguration  Requirements 

Reconfiguration  la  responsible  for  monitoring  the  health  of  all  the  AIDS 
hardware  and  for  reconfiguring  the  system  In  response  to  hardware  failures. 
Reconfiguration  does  not  exist  as  a  single  program;  rather.  It  Is  distributed 
among  a  central  Reconfiguration  Process  and  the  fxinctlons  associated  with  the 
various  AIDS  hardware  modules. 

3. 4. 5.1  Reconfiguration  Inputs 


Input 

Source 

Frequency 

AN/AYK-IA  Hardware  Status 

IFPM 

5  Hz 

AN/AYK-14  Failure  Interrupt 

AN/AYK-14  (via  SDEX/M) 

Aperiodic 

MIIXR  Status  Tables 

Other  MIDERs 

60  Hz 

AIDS  Module  Failures 

AIDS  Modules 

Aperiodic 

Crew-Diagnosed  Failures 

Crew^vla  ICS) 

Aperiodic 

Current  System  Status 

Systan  Status  Table 

5  Hz 

Revised  AN/AYK-14  Program 

Mass  Memory 

Aperiodic 

Revised  Formats 

Mass  Memory 

Aperiodic 

Revised  ICP  Tables 

Mass  Memory 

Aperiodic 

3. 4. 5. 2  Reconfiguration  Processing 

The  Reconfiguration  Process  shall  control  the  configuration  of  both  the 
AIDS  software  In  the  data  processor  and  the  AIDS  hardware  modules.  The  Recon¬ 
figuration  Process  executes  as  the  primary  HOL  process  and  as  such  shall  be 
responsible  for  activation  of  all  other  processes.  In  addition  to  this  respon¬ 
sibility,  the  Reconfiguration  Process  shall  coordinate  the  activity  of  the 
reconfiguration  functions  described  below,  periodically  Invoke  the  IFPM  pro¬ 
cedures,  periodically  record  the  System  Status  Table  on  the  mass  memory  and 
periodically  exchange  status  with  the  other  MIDERs.  This  last  Item  Is  described 
In  detail  below. 

The  Inter-MIDER  status  exchange  is  performed  by  "send'*  and  "receive'*  pro¬ 
cesses  in  each  MIDGR.  (These  processes  are  controlled  by  the  Reconfiguration 
Process.)  At  60  Hz,  the  send  process  appends  the  current  clock  time  to  the 
MIDER  status  table,  and  sends  the  table  to  the  other  data  processor.  The  pro¬ 
cess  need  not  wait  for  any  success/failure  Indication  from  the  transmission. 
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Also  at  60  Hz,  the  receive  process  compares  the  Input  table  entries  with  the 
corresponding  entries  In  Its  own  table  and  the  differences  are  noted.  If  the 
time  accompanying  the  Input  table  Is  greater  (l.e. ,  later)  than  the  current 
time  In  the  receiving  data  processor,  the  received  time  is  used  to  reset  the 
current  time;  this  assures  that  the  clock  times  In  the  two  data  processors  will 
eventually  differ  by  no  more  than  the  transmission  time. 

If  Input  tables  fall  to  arrive  at  60  Hz,  the  receive  process  attempts  to 
isolate  the  failure  point,  which  could  be  anything  from  the  other  data  processor 
(l.e.,  the  rest  of  the  ocher  MIOER  works  well),  to  complete  failure  of  the  other 
MIDER  (e.g. ,  its  MIDER  bus  failed)  or  failure  of  the  entire  system.  This  last 
case  can  be  Ignored  here  because  It  Is  recognized  more  quickly  through  ocher 
means.  The  failure  polnt(a)  are  determined  by  sending  a  request  to  each  peri¬ 
pheral  In  the  ocher  MIDER  which  could  be  used.  All  those  entries  In  Che  system 
status  table  are  marked  "down"  until  a  peripheral  responds.  When  a  MIDER  status 
table  Is  received  after  missing  one  or  more  periods,  Che  Internal  system  status 
Is  updated  and  Che  process  returns  to  Its  normal  cycle. 

Each  reconfiguration  function  has  two  subfunctions:  failure  monitoring  and 
failure  response.  Failure  monitoring  Is  continuously  performed;  failure  re¬ 
sponse  Is  Invoked  only  when  failure  monitoring  diagnoses  a  failure.  Both  Che 
falltire  monitoring  and  response  processing  are  distributed  among  Che  data 
processor  programs  according  to  their  responsibilities.  For  example,  the  OSS 
monitors  and  responds  to  mass  memory  failures,  the  ODS  responds  to  display 
failures,  and  DPICS  responds  to  ICP  failuresi.  The  complete  allocation  of 
reconfiguration  responsibility  Is  described  In  Table  3-11,  Che  System  Recon¬ 
figuration  Specification  Table.  This  table  describes  for  each  failure  the 
data  processor  program  which  responds  to  the  failure,  the  program's  response, 
and  Che  functional  effect  on  AIDS  as  experienced  by  Che  crew.  Before  discuss¬ 
ing  Che  table  in  more  detail,  a  general  description  of  failure  monitoring  Is 
presented. 

The  Reconfiguration  Process  and  Che  reconfiguration  functions  perform  both 
active  and  passive  failure  monitoring.  The  active  failure  monitoring  comprises 
a  periodic  activation  of  the  IFPM  procedures,  exchanging  MIDER  status  tables 
among  Che  MIDER' s,  and  maintaining  timeout  limits  for  each  external  avionics 
subsystem  which  Is  supposed  Co  transmit  Information  to  AIDS  periodically.  Pas¬ 
sive  failure  monitoring  comprises  responding  to  Che  AN/AYK-14  failure  Inter¬ 
rupts,  responding  to  failures  diagnosed  by  Che  various  AIDS  modules  BIT  pro¬ 
cessing,  and  responding  to  crew  commands  which  Indicate  a  hardware  failure. 

As  stated  above.  Table  3-11  describes  the  specific  response  performed  for 
each  failure  diagnosed  by  the  data  processor.  Before  performing  this  specific 
response,  the  following  common  response  shall  be  performed.  First,  the  failure 
shall  be  entered  In  the  System  Status  Table.  Next,  the  SIGNAL  ERROR  OSS  function 
shall  be  called.  This  call  will  cause  Che  occurrence  of  the  failure  to  be  dis¬ 
played  to  Che  crew.  In  addition,  this  call  may  result  In  termination  of  the 
process  which  diagnosed  Che  failure.  Such  termination  would  be  requested  If,  as 
a  result  of  Che  failure,  no  further  processing  by  the  process  would  be  produc¬ 
tive.  Finally,  following  performance  of  Che  specific  response,  any  resulting 
changes  In  system  status  shall  be  entered  in  the  System  Status  Table. 
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Several  of  the  entries  In  Table  3-11  which  describe  specific  failure  response 
require  amplification.  The  "Functional  Aspect"  column  describes  the  aspect  of 
the  failure  as  experienced  by  the  crew.  The  aspect  may  be  one  of  the  following: 
"none,"  "system  degradation,"  or  "system  failure."  "None"  Indicates  that  a 
hardware  module  has  failed  for  which  there  Is  a  completely  redundant  module 
which  when  utilized  results  In  no  perceivable  system  degradation.  "System 
degradation"  Indicates  that  either  the  volume  of  Information  exchanged  with 
the  crew  will  be  decreased  (e.g. ,  a  format  la  no  longer  displayed)  or  that  the 
exchange  will  require  more  effort  by  the  crew  (e.g.,  the  pilot  must  use  an 
ICP,  rather  than  the  MCP,  to  enter  mission  mode  changes).  Finally,  "system 
failure"  Indicates  that  no  further  Information  exchange  will  occur. 

In  response  to  5  of  the  10  AN/AYK-14  fault  Interrupts,  Table  3-11  speci¬ 
fies  a  "restart  program"  response.  The  five  Interrupts  with  this  response!  are 
caused  by  a  software  malfunction.  The  restart  program  response  assumes  that 
the  malfunction  occurred  as  a  result  of  the  software  experiencing  a  combination 
of  Inputs  which  had  not  been  anticipated  nor  tested.  Further,  It  Is  assumed 
that  If  the  program  Is  reinitialized  and  restarted,  the  combination  will  not 
reoccur.  Should  the  combination  persist  and  the  program  continue  to  malfunc¬ 
tion,  the  crew  may  then  override  the  data  processor  by  deselecting  the  malfunc¬ 
tioning  program. 

For  several  failures.  Table  3-11  distinguishes  between  "single"  and  "com¬ 
plete"  failure.  The  distinction  Is  used  for  duplicated  hardware  modules.  These 
modules  Include  the  mass  memory,  the  Itms,  the  Xbus,  and  the  TCP's.  A  single 
failure  is  one  In  which  one  of  the  redundant  modules  has  failed  and  at  least 
one  remains  operational.  A  complete  failure  occurs  when  all  the  redundant 
modules  have  failed. 

The  last  entry  In  Table  3-11  requiring  amplification  Is  the  "automatic"  con¬ 
figuration  which  Is  used  following  complete  failure  of  all  the  command  Input 
devices.  The  automatic  configuration  selects  for  each  mission  mode  the  set  of 
formats  which  provides  the  maximum  amount  of  mlsslon-crltlc&l  and  fll^t- 
crltlcal  Information  output  to  the  crew.  Further,  the  automatic  configuration 
shall  change  mission  modes  according  to  the  changes  In  the  aircraft  status. 

3. 4. 5. 3  Reconfiguration  Outputs 


Output 

Destination 

Frequency 

Revised  System  Status 

System  Status  Table 

60  Hz 

Revised  Routing  Table 

Mbus  Controller 

Aperiodic 

Revised  Format  Allocation 

RSC's  and  Displays 

Aperiodic 

Revised  ICP  Allocation 

DPICS  and  MPICS 

Aperiodic 

Revised  AM/AYK-14  Program 

AN/AYK-14  Memory 

Aperiodic 
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Output  PeBtlnatlon  Frequency 

AN/AYK-14  Power  Recovery  Code  Initialization  Code  Word  Aperiodic 

Failure  Notification  Crew  (via  ODS)  Aperiodic 

3. 4. 5. 4  Reconfiguration  Special  Requirements 


None. 

3.4.6  Overlay  Requirements 

The  Overlay  function  of  the  OSS  Is  responsible  for  loading  the  data  pro¬ 
cessor  with  a  new  configuration  of  application  programs.  The  programs  are 
retrieved  from  the  mass  memory  system.  The  Overlay  function  Is  Invoked  by  the 
Reconfiguration  Process  In  response  to  either  a  mission  mode  change  cr  a  hard- 


ware  failure. 

3 . 4 . 6 . 1  Overlay  Inputs 

Input 

Source 

Frequency 

New  Configuration  File  Name 

Reconf Iguratlon 

Aperiodic 

Process 

3. 4. 6. 2  Overlay  Processing 

The  Overlay  function  shall  first  determine  that  only  the  Reconfiguration 
Process  Is  active;  that  is,  there  are  no  active  processes  which  are  going  to  be 
overlaid.  Then  the  requested  file  shall  be  read  Into  memory.  The  requested 
file  must  be  a  read-only  file  or  an  error  is  diagnosed.  The  OSS  uses  the  File 
System  to  read  the  overlay  file.  Then  the  OSS  returns  control  to  the  Recon¬ 
figuration  Process  which  activates  the  next  level  of  .  ^.cesses  and  thus  the 
processing  for  the  new  mode  Is  begun. 

3. 4. 6. 3  Overlay  Outputs 


Output 

Destination 

Frequency 

New 

Configuration  Program 

Data  Processor  Memory 

Aperiodic 

New 

Page  Register  Settings 

AN/AYK-14  Page  Register 
(via  SDEX/M) 

Aperiodic 

3. 4. 6. 4 

Overlay  Special  Requirements 

None. 
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3. A. 7  Briefing  Information  Entry  Requirements 

The  Briefing  Infornatlon  Entry  function  of  the  OSS  Is  responsible  for 
reading  the  mission-specific  data  contained  on  the  Briefing  Information  Entry 
Device  (BIED)  tape  and  transferring  this  data  to  the  appropriate  destination, 
both  within  and  outside  of  AIDS. 

3. 4. 7.1  Briefing  Information  Entry  Inputs 

Input  Source  Frequency 

Initiate  Briefing  Informa-  Pilot  Once 

tlon  Entry  Command 

Briefing  Information  Data  BIED  Once 

Records 

Data  Destination 
Data 

3. 4. 7. 2  Briefing  Information  Entry  Processing 

The  Briefing  Information  Entry  function  of  the  OSS  will  be  activated  by 
DPICS  In  response  to  the  appropriate  command  from  the  ICS.  The  OSS  shall  read 
the  mission-specific  data,  record  by  record.  Bach  record  will  be  formatted  to 
facilitate  routing  of  the  data.  In  particular,  if  the  data  Is  to  be  stored 
within  AIDS,  the  record  will  describe  the  file  %thlch  must  be  created  In  mass 
memory  to  contain  the  Information.  Using  this  Information,  the  OSS  shall  re¬ 
quest  the  File  System  to  create  a  file  of  the  required  length  and  shall  then 
copy  the  mission  data  from  the  BIED  Into  this  file.  After  copying  the  data, 
the  OSS  shall  then  redefine  the  file  as  read-only. 

If  the  data  In  a  BIRD  record  Is  to  be  stored  In  an  external  avionics  sub¬ 
system,  the  record  will  describe  the  required  OUTPUT  MESSAGE  requests  that 
the  OSS  must  issue  to  transmit  the  data  to  its  destination. 

After  processing  all  the  data  records,  the  OSS  shall  update  the  System 
Status  Table  to  Indicate  completion  of  Briefing  Information  Entry.  The  OSS 
shall  Inform  the  crew  that  the  Information  entry  has  been  completed. 


3. 4. 7. 3  Briefing  Information  Entry  Outputs 

Output  Destinaton  Frequency 

Mission  Data  Files  Mass  Memory  Once 

Mission  Data  Messages  External  Avionics  Once 

Subsystems 

Revised  System  Status  System  Status  Table  Once 

Briefing  Information  Entry  Crew  (via  ODS)  Once 

Complete  Message 
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3. 4. 7. 4  Briefing  Information  Entry  Special  Requirements 

None. 

3.4.8  Switch  Processing  Requirements 

The  Switch  Processing  function  shall  be  responsible  for  the  processing  of 
crew  Input  through  the  ICS.  Switch  Processing  shall  Involve  Interpretation  and 
routing  of  switch  commands  (through  the  use  of  ACOL-speclfled  command  interpre¬ 
tations),  validation  of  keyset  entries,  and  notification  to  the  crewmember  of 
Invalid  keyset  entries. 

The  processing  requirements  specified  In  this  section  are  the  generic  AIDS 
switch  processing  requirements.  These  requirements  are  those  necessary  to  ac¬ 
commodate  any  ICP  switch  configuration  which  Is  acceptable  by  the  AIDS  Command 
Formatter.  Appendix  B  of  this  specification  contains  the  specific  switch 
configurations  for  the  V/STOL-pllot,  SENSO,  TACCO,  CICO,  and  ACO  ICPs.  The 
AIDS  V/STOL  switch  processing  shall  correctly  Interpret  the  ACOL-generated 
tables  corresponding  to  each  of  these  configurations. 

3. 4. 8.1  Switch  Processing  Inputs 

Input 

ACOL  Consnand  Table  Fields 
Command  Destination 
Conmand  Code 
Keyset  Value  Range 
Force  Stick  Indicator 

MPICS  Command  Fields 
Command  Index 
Keyset  Value  (Optional) 

Conmand  Receipt  Time 

3. 4. 8. 2  Switch  Processing 

Switch  Processing  of  an  MPICS  switch  command  shall  be  performed  on  the 
basis  of  the  command's  specific  processing  requirements.  Using  the  MPICS 
message's  command  Index,  the  corresponding  ACF-generated  table  entry  shall  be 
Interrogated  to  establish  the  current  command's  description.  If  the  ACF  entry 
Indicates  that  the  command  possesses  an  "a'^sociated  value,"  then  Its  value 
type  (keyset  or  preset)  will  be  established.  If  a  keyset  value  (i.e.,  a  data 
entry  on  the  ICP)  Is  Indicated,  Switch  Processing  shall  validate  the  keyset 
value  with  its  defined  acceptable  value  range.  If  the  keyset  value  fails  Its 
prescribed  range  test,  a  diagnostic  message  shall  be  emitted  to  both  a  desig¬ 
nated  SAD  and  to  MPICS. 

If  Force  Stick  processing  Is  required,  the  DPICS  Force  Stick  process  (ref¬ 
erence  Section  3.4.9)  shall  be  activated  (via  OSS  request).  If  HOTAS  processing 
Is  required,  the  DPICS  HOTAS  process  (reference  Section  3.4.10)  shall  be  activated 


Source  Frequency 

AIDS  Command  Formatter  Off-Line 

MPICS  Aperiodic 
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(via  OSS  request).  In  response  to  a  switch  command  requiring  the  termination 
of  Force  Stick  processing.  Switch  Processing  shall  terminate  the  Force  Stick 
process  (via  OSS  terminate  request). 

As  defined  by  Its  command  specification,  the  command  may  be  destined  for 
either  an  external  avionics  subsystem  or  an  AIDS  module.  For  the  former,  the 
command  value.  If  any,  shall  be  appended  to  the  formatted  message  contained  as 
part  of  Its  command  specification  prior  to  requesting  the  OSS  to  transmit  the 
message.  For  the  latter,  the  command  shall  be  stored  In  the  DPICS  Input  com¬ 
mand  queue  associated  with  the  Intended  destination  (e.g.,  a  display  function). 

3. 4. 8. 3  Switch  Processing  Outputs 

Output 

Keyset  Entry  Diagnostic 

Keyset  Entry  Diagnostic 

Internal  Command  Queue 
Fields 

Command  Code 
Command  Value 

External  Coonand  Message 
Fields 

/  Command  Code 

^  Command  Value 

Force  Stick  Activation 

Parameters 

Force  Stick  Value 
Destination 
Force  Stick  Trans¬ 
formation  Fun  .tlon 

3. 4. 8. 4  Switch  Processing  Special  Requirements 

1.  The  Switch  Processing  function  shall  be  structured  so  that  the  ACF- 
generated  command  specification  tables  may  be  Integrated  into  the  Switch  Pro¬ 
cessing  code.  The  details  of  this  integration  appear  In  the  "AIDS  Command 
Formatter  Users  Guide"  (King  80) . 

2.  The  Switch  Processing  function  shall  be  reentrant. 

3.4.9  Force  Stick  Requirements 

The  Force  Stick  function  Is  responsible  for  periodically  accepting  force 
stick  readings  (X  and  Y  digital  vaJ  les),  converting  these  readings  on  the  basis 
of  the  associated  transformation  function,  and  transmitting  these  readings  to 
the  destination  system  to  which  the  force  stick  is  currently  allocated. 


Destination 
SAD  Program 
MPICS  (via  OSS) 

AIDS  Function 

External  Avionics 
Subsystem  (via  OSS) 


Force  Stick  Function  Aperiodic 

(via  OSS) 


Frequency 

Aperiodic 

Aperiodic 

Aperiodic 

Aperiodic 
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3. 4. 9.1  Force  Stick  Inputs 


Input 

Destination  System 

Transformation  Function 


Source 


Frequency 


Switch  Processing 
Function 


Once 


Switch  Processing 
Function 


Once 


Force  Stick  Values  MPICS  (via  OSS)  20  Hz 

%  Value 
Y  Value 


3. 4. 9. 2  Force  Stick  Processing 

In  response  to  a  switch  command  requiring  force  stick  Input,  Switch  Pro¬ 
cessing  shall  activate  the  Force  Stick  function.  As  part  of  this  activation. 
Switch  Processing  shall  Identify  the  destination  system  to  which  the  force 
stick  values  are  to  be  routed  and  the  transformation  function  defining  how  the 
values  are  to  be  Interpreted.  Switch  Processing  will  also  request  the  OSS  to 
begin  accepting  periodic  force  stick  value  messages  from  MPICS. 


Upon  the  periodic  reception  of  force  stick  readings,  the  Force  Stick  func¬ 
tion  shall  convert  these  digital  values  using  the  destination  system's  asso¬ 
ciated  transformation  function.  The  transformation  function  will  be  a  piece- 
wise  linear  function  defining  the  association  of  the  force  stick  values  with 
the  designated  destination  system. 


Processing  of  the  transformed  force  stick  readings  shall  be  dependent  upon 
Its  Intended  destination  system.  If  the  destination  system  Is  an  external  avi¬ 
onics  subsystem,  an  associated  force  stick  message  shall  be  constructed  and 
transmitted  together  with  the  current  values  via  the  Xbus.  Otherwise,  for  an 
Internal  AIDS,  the  force  stick  values  shall  be  routed  to  the  destination’s 
DPICS  Input  queue.  Vlhen  Switch  Processing  receives  the  command  signifying  the 
termination  of  Force  Stick  processing,  the  OSS  shall  be  requested  to  terminate 
the  Force  Stick  process. 


3. 4. 9. 3  Force  Stick  Outputs 
Output 

Transformed  Force  Stick 
Values 
X  Value 
Y  Value 


Destination  Frequency 

External  Avionics  20  Hz 

Subsystem  (via  OSS) 
or  AIDS  Program 
(via  DPICS  Input  Queue) 


3. 4. 9. 4  Force  Stick  Special  Requirements 


1.  The  Force  Stick  function  shall  be  reentrant. 
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3»4.10  HOTAS  Requirements 

The  HOTAS  requirements  are  TBD. 

3*4. 11  Voice  Recognition  Requirements 

The  voice  recognition  requirements  are  TBD. 

3.4.12  Graphics  Support  Function 

The  Graphics  Support  function  of  the  OSS  provides  the  ODS  with  a  high-level 
Interface  to  the  RSGs  and  the  symbol  generators  In  the  HUD  and  the  SADs. 

3.4.12.1  Graphics  Support  Inputs 


Input 

Source 

Frequency 

CONFIGURE  SG  Parameters 

Symbol  Generator  Identifier, 
Configuration  Parameters 

ODS 

Aperiodic 

ASSIGN  FORMAT  TO  SG  Parameters 
Format  Identifier 

Symbol  Generator  Identifier 

ODS 

Aperiodic 

PUT  PROCEDURES  Parameters 

Rapid  Change  Name 

Replacement  Value 

ODS 

Aperiodic 

UPDATE  SG  Parameter 

Symbol  Generator  Identifier 

ODS 

Aperiodic 

STOP  SG  Parameter 

Syid)ol  Generator  Identifier 

ODS 

Aperiodic 

Format  Change  Command 

Templates 

Mass  Memory 
(via  OSS) 

Aperiodic 

3.4.12.2  Graphics  Support  Processing 


The  details  of  Graphics  Support  processing  will  be  described  separately  for 
CONFIGURE  SG,  ASSIGN  FORMAT  TO  SG,  the  generic  Put  Procedures,  UPDATE  SG  and 
STOP  SG.  Before  proceeding  to  these  details,  the  relevant  data  structures  will 
be  summarised. 

For  each  symbol  generator  the  Graphics  Support  shall  maintain  a  data  block 
called  SG  Control  Block  which  describes  Che  state  of  the  symbol  generator.  This 
state  includes  an  indication  of  whether  a  format  has  been  loaded  Into  the  symbol 
generator,  and,  if  so:  (1)  an  indication  of  whether  the  symbol  generator  has  been 
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started;  (2)  a  list  of  format  change  command  templates  for  the  current  format; 
and  (3)  an  Indication  of  which  of  these  templates  have  been  changed  since  the 
last  update  was  transmitted  to  the  symbol  generator. 

In  euldltlon  to  the  S3nnbol  generator  Control  Blocks,  data  structures  shall 
exist  for  each  Individual  format.  For  each  format  which  can  be  displayed  by 
a  particular  configuration  of  the  ODS,  there  is  a  format  description  data  struc¬ 
ture  and  several  rapid  data  change  data  structures.  There  Is  the  format  data 
structure  which  contains  the  file  name  of  Its  SADI  program.  Each  rapid  change 
data  structure  Identifies  the  format  containing  the  rapid  change  and  what 
parts  and  In  what  ways  the  SADI  program  (In  a  symbol  generator)  should  be 
changed  when  the  change  occurs.  The  use  of  these  data  structures  Is  described 
In  the  following  descriptions  of  the  Graphics  Support  processing. 

The  CONFIGURE  SG  procedure  shall  accept  as  parameters  the  specification  of 
a  S3rmbol  generator  and  the  desired  configuration  parameters.  CONFIGURE  SG 
simply  updates  the  appropriate  symbol  generator  Control  Block  and  transmits 
the  required  commands  to  the  symbol  generator. 

The  first  action  of  ASSIGN  FORMAT  TO  SG  shall  be  to  perform  all  the  process¬ 
ing  associated  with  STOP  SG.  Next,  the  File  System  shall  be  Invoked  to  transmit 
the  SADI  program  for  the  specified  format  into  the  specified  symbol  generator. 

At  the  same  time,  the  display  change  command  templates  for  the  format  shall  be 
read  (via  the  File  System)  Into  the  Control  Block  for  the  specified  symbol  gen¬ 
erator.  Finally,  the  fact  that  the  s3rmbol  generator  needs  to  be  started  shall 
be  recorded  In  Its  Control  Block. 

The  processing  for  each  Put  Procedure  shall  begin  by  recording  the  replace¬ 
ment  val«ie  In  the  specified  rapid  change  data  stiructure.  Next,  checking  shall 
be  performed  to  see  If  the  format  being  changed  is  loaded  In  any  symbol  gener¬ 
ator.  If  not,  no  further  action  Is  required.  If  the  format.  Is  loaded  In  a 
symbol  generator,  the  appropriate  display  change  command  template  shall  be 
altered  so  that  the  next  time  It  is  sent  to  the  symbol  generator,  the  SAT' 
program  will  change  and  a  new  picture  will  therefore  be  displayed.  The  f.  •  . 
that  the  template  has  changed  shall  be  recorded  for  use  by  UPDATE  FORMAT. 

UPDATE  FORMAT  shall  first  transmit  all  of  the  format's  display  change  com¬ 
mands  which  have  been  modified  since  the  last  call  to  UPDATE  FORMAT  for  the 
specified  format.  Next  UPDATE  FORMAT  determines  the  lowest  level  of  the  SADI 
program  which  must  be  reinterpreted  by  the  symbol  generator  to  affect  all  the 
transmitted  display  changes.  If  the  symbol  generator  has  not  yet  st8{:;:ed  to 
display  the  format  It  contains.  Interpretation  must  begin  at  level  zero.  After 
determining  the  required  level,  UPDATE  FORMAT  shall  transmit  an  Interpret  com¬ 
mend  to  the  symbol  generator. 

The  STOP  SG  function  undoes  the  effect  of  an  ASSIGN  FORMAT  TO  SG  invocation. 
If  the  specified  symbol  generator  does  not  have  a  format  loaded  Into  It,  no 
action  Is  required.  Otherwise,  STOP  SG  shall  signal  the  symbol  generator  to 
stop  processing  the  SADI  program  and  to  remove  from  the  crew's  view  any  displayed 
Information  resulting  from  previous  processing.  STOP  SG  shall  mark  the  appro¬ 
priate  format  to  Indicate  that  It  Is  no  longer  being  displayed. 


3.4.12.3  Graphics  Support  Outputs 

Output 

Destination 

Frequency 

Symbol  Generator  Stop  Command 

Symbol  Generator  (via  OSS) 

Aperiodic 

S3nnbol  Generator  Initial  Load 
Command 

Symbol  Generator  (via 

File  System) 

Aperiodic 

Symbol  Generator  Display  Change 
Command 

Symbol  Generator  (via  OSS) 

Aperiodic 

Symbol  Generator  Interpret 

Command 

S3mbol  Generator  (via  OSS) 

Aperiodic 

Updated  Display  Change  Command 

Symbol  Generator  Control 
Block 

Aperiodic 

Symbol  Generator  Status 

Symbol  Generator  Control 
Block 

Aperiodic 

Updated  Rapid  Change  Component 

Rapid  Change  Data  Structure 

Aperiodic 

Value 


3.4.12.4  Graphics  Support  Special  Requirements 

The  Graphics  Support  procedures  shall  be  reentrant. 

3.4.13  Voice  Synthesis  Requirements 

The  voice  synthesis  requirements  are  TBD. 

3.4.14  Video  Input  Requirements 

The  video  Input  requirements  are  TBD. 

3.4.15  Flight  Data  Display  Requirements 

The  Flight  Data  Display  function  performs  all  processing  associated  with 
flight  S3mbology  display.  Flight  Input  sources  are  NAV,  JTIDS,  the  BIED,  the 
Helmet  Position  Sensor,  and  DPICS;  display  update  processing  Is  performed  for 
the  HUD,  HMD,  VSD,  and  HSD. 


t 


101 


Frequency 


75j57J50 

3.4.15.1  Flight  Data  Display  Inputs 


Input  Source 


Roll 

NAV 

60  Hz 

Pitch 

NAV 

60  Hz 

True  Heading 

NAV 

20  Hz 

Magnetic  Reading 

NAV 

20  Hz 

North  Velocity 

NAV 

20  Hz 

East  Velocity 

NAV 

20  Hz 

Vertical  Velocity 

NAV 

20  Hz 

Radar  Altitude 

NAV 

20  Hz 

Barometric  Altitude 

NAV 

20  Hz 

True  Airspeed 

NAV 

20  Hz 

Indicated  Airspeed 

NAV 

20  Hz 

Mach  Number 

NAV 

20  Hz 

Hind  Speed 

NAV 

20  Hz 

Wind  Bearing 

NAV 

20  Hz 

Latitude 

NAV 

20  Hz 

Longitude 

NAV 

20  Hz 

Roll  Command 

JTIDS 

20  Hz 

Pitch  Command 

JTIDS 

20  Hz 

Command  Heading 

JTIDS 

20  Hz 

Command  Altitude 

JTIDS 

20  Hz 

Command  Airspeed 

JTIDS 

20  Hz 

Vertical  (Glide  Slope)  Error 

JTIDS 

20  Hz 

Lateral  (Localizer)  Error 

JTIDS 

20  Hz 

Time 

JTIDS 

20  Hz 

Data  Link  Ref  Pt,  Lat. 

JTIDS 

20  Hz 

Data  Link  Ref  Pt,  Long. 

JTIDS 

20  Hz 

Wave-Off 

JTIDS 

20  Hz 

TACAN  Range 

JTIDS 

20  Hz 

TACAN  Bearing 

JTIDS 

20  Hz 

Waypolnt/Checkpolnt  Pos,  Lat. 

BIED 

Once 

Waypolnt/Checkpolnt  Pos,  Long. 

BIED 

Once 

Helmet  Roll 

Helmet 

Position 

Sensor 

60  Hz 

Helmet  Pitch 

Helmet 

Position 

Sensor 

60  Hz 

Helmet  Heading 

Helmet 

Position 

Sensor 

60  Hz 

Format  Controls 

Pilot 

(via  MPICS  and 

Aperiodic 

DPICS) 

3.4.15.2  Flight  Data  Display  Processing 

The  Flight  Data  Display  Processing  comprises  both  functions  common  to 
all  the  formats  controlled  by  Flight  Data  Display  and  functions  specific 
to  each  format.  The  common  processing  Includes  three  subfunctions:  Input 
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data  processing,  sensor  validity  verification,  and  sensor  failure  and  recovery 
processing.  In  the  description  below,  Che  three  common  subfunctions  are  de¬ 
scribed  first,  then  the  generic  update  display  processing  which  Is  applicable 
CO  all  formats,  and  finally  the  specific  processing  required  for  each  format. 
Each  format's  processing  description  contains  a  brief  explanation  of  the  for¬ 
mat's  use  and  Its  s3rmbology,  a  figure  Illustrating  the  format,  and  a  table 
specifying  Che  required  symbology  dynamics. 

Periodically  at  60  Hz  and  20  Hz  the  Input  Data  Processing  shall  process  the 
Input  data  buffers  (maintained  by  the  OSS)  which  contain  each  flight  parameter 
value  and  associated  sample  reference  time.  For  each  Input  parameter  requiring 
processing  (all  sensor  values  are  not  sampled  at  the  same  rate),  a  comparison 
shall  be  made  between  Che  Input  buffer  sample  time  and  Che  sensor's  most  recent 
sample  time  maintained  In  Che  flight  parameter  data  base.  In  the  event  that 
Che  Input  buffer  time  la  more  recent  (l.e.,  availability  of  a  new  sensor  mea¬ 
surement)  Che  flight  parameter  value  shall  be  converted  Into  Its  corresponding 
AIDS  Internal  format.  The  converted  parameter  value  and  associated  sample 
time  shall  then  be  scored  In  the  flight  parameter  data  base  for  subsequent  use 
In  Che  validity  verification  process.  In  Che  event  that  a  new  sensor  measure¬ 
ment  was  not  received,  Che  sensor  failure  and  recovery  process  shall  be  in¬ 
voked  . 

Validity  Verification  Processing  shall  evaluate  those  flight  parameter 
values  specifically  designated  as  having  been  updated  from  a  previous  sample 
period.  Each  changed  flight  parameter  value  shall  Initially  be  evaluated  In 
accordance  with  Its  defined  acceptable  sensor  value  range  and  rate  of  change. 
Each  sensor  parameter  falling  Its  boundary  value  tests  shall  then  be  evaluated 
using  a  specialized  verification  test  If  the  parameter  value  contains  a  discon¬ 
tinuity  In  Its  value  range*  For  example,  the  flight  heading  sensor  value  may 
change  from  358  to  0  without  violating  the  rate  of  change.  Failure  to  satisfy 
its  verification  tests  shall  result  in  Che  associated  sensor  being  designated 
as  having  failed.  Additionally,  Che  sensor's  associated  '‘reactivation  count" 
shall  be  reset  prior  to  Invoking  Che  sensor  failure  and  recovery  process.  The 
reactivation  count  Is  the  number  of  valid  sensor  Inputs  required  before  the 
sensor  can  be  designated  acceptable. 

The  reactivation  count  of  each  sensor  parameter  which  satisfies  Its  veri¬ 
fication  test  and  Is  currently  designated  as  failed  shall  be  Incremented.  Addi¬ 
tionally  Che  sensor's  status  shall  be  set  to  acceptable  If  the  reactivation 
count  exceeds  the  preestablished  reactivation  threshold. 

Update  Display  shall  perform  display  device  reallocation,  format  modifica¬ 
tions,  and  the  update  of  format  symbology.  An  active  display  device  which 
has  failed  shall  be  deactivated  and  Its  associated  backup  display  device.  If 
any,  shall  be  activated.  Formats  requiring  a  display  status  change  (placement 
onto/removal  from  a  display)  shall  similarly  be  modified  as  required.  If  the 
display  device  Is  currently  In  Che  inactive  state,  processing  Is  completed. 
Otherwise,  subsequent  processing  shall  be  based  upon  specific  display  process¬ 
ing  requirements. 
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within  the  flight  parameter  data  base,  each  currently  active  S3rmbol  shall 
be  examined  to  determine  whether  a  change  In  Its  visibility  status  Is  required. 
For  each  currently  visible  s3nabol.  If  a  positional  status  change  Is  required. 

Its  format  position  shall  then  be  modified.  The  following  text  presents  a  de¬ 
scriptive  summary  of  the  Flight  Data  Display  formats. 

The  HDD  shall  present  four  formats  to  the  pilot  on  the  basis  of  the  existing 
mission  mode.  The  formats  are:  Taxi,  Takeoff /Cruise,  Transition,  and  Landing. 

Figure  3-30  Illustrates  the  HDD  Taxi  format,  which  shall  be  displayed  when 
the  pilot  selects  the  "TAXI"  mode.  The  format  contains  only  a  heading  scale. 
Table  3-12  specifies  the  Taxi  format  dynamics. 

Figure  3-31  Illustrates  the  HUD  Takeoff /Cruise  format,  which  Is  displayed 
when  any  of  the  takeoff  modes,  the  CBUISE  mode,  or  the  SEARCH  mode  Is  selected. 
The  format  displays  aircraft  pitch,  roll,  vertical  velocity,  airspeed  heading 
and  altitude  values  and  the  corresponding  command  values.  The  format  also  dis¬ 
plays  the  warning  and  breakaway  symbols.  Table  3-13  specifies  the  format's 
dynamics . 

Figure  3-32  Illustrates  the  HUD  Transition  format,  which  Is  displayed  when 
the  TRANSITION  TO  LANDING  mode  la  selected.  The  format  displays  the  aircraft's 
heading,  airspeed,  altitude,  velocity  vector,  angle  of  attack,  glldeslope  de¬ 
viation,  and  localizer  deviation.  Table  3-14  specifies  the  format's  dynamics. 

Figure  3-33  illustrates  the  HDD  Landing  format,  which  is  displayed  when 
any  of  the  three  landing  modes  (CONVENTIONAL,  SHORT,  VERTICAL)  is  selected. 

The  format  displays  a  perspective  Image  of  the  runway,  along  with  the  aircraft's 
pitch,  heading,  lateral  acceleration,  speed,  vertical  velocity,  and  engine  tor¬ 
que.  Coimsand  symbology  for  glldeslope,  spe^,  heading,  and  vertical  velocity 
Is  also  displayed.  Table  3-15  specifies  the  format's  dynamics. 

The  Helmet-Mounted  Display  presents  two  formats:  Normal  and  Search.  The 
HMD  Normal  format  displays  information  similar  to  the  HUD  formats.  The  Normal 
format  is  displayed  in  all  mission  modes  except  SEARCH.  The  symbology  visible 
In  the  Normal  format  is  a  function  of  mission  mode.  Figure  3-34  illustrates 
the  Normal  format  with  all  possible  symbology.  During  the  TAXI  mode,  only  the 
horizon  with  heading  labels  is  visible.  During  the  three  takeoff  modes,  the 
two  transition  modes,  and  the  CONVENTIONAL  LANDING  mode,  the  format  contains 
a  pitch  ladder,  velocity  vector,  and  flight  director.  During  the  CRUISE,  VERTI¬ 
CAL  LANDING,  and  SHORT  LANDING  modes,  only  the  horizon  line  is  visible.  Table 
3-16  specifies  the  Nonaal  format's  dynamics. 
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TABLE  3-13.  HDD  TAKEOPF/CSDISB  FORMAT  DTHAHICS  (Fage  I  of  2) 


Symbol 

Controlling  Parameter 

Dynami cs 

Velocity  Vector 

Roll,  Pitch,  True  Heading, 

North  Velocity,  East  Velocity, 
Vertical  Velocity 

Position 

Flight  Director 

TBD 

Position 

Breakaway 

TBO 

Visibility 

Warning  Indicator 

TBO 

Visibility 

Horizon  Line 

Pitch,  Roll 

Position,  Rotation 

Pitch  Ladder 

Pilot  Control 

Pitch,  Roll 

Visibility 

Position,  Rotation 
Pitch  Labels  Text 
Characters 

Heading  Scale 

Pilot  Control 

Magnetic  Heading 

Comnand  Heading 

Visibility 

Tick  Marks  x*pos1tion 
Tape  Labels  Text 

Characters 

Command  X>pos1t1on 

Vertical  Velocity 

Pilot  Control 

Visibility 

Scale 

Vertical  Velocity 

Tick  Marks  -position 
Tape  Labels  Text 

1 

TBD 

Command  Y-posItlon 

1 

Airspeed  Scale 

Pilot  Control 

True  Airspeed 

Command  Airspeed 

Visibility 

Tick  Marks  Y-posItlon 
Tape  Labels  Text 
Characters 

Command  Y-posItlon 

1 

Mach  Number 

Pilot  Control 

Visibility 

1 

Scale 

Mach  Number 

Tick  Marks  Y-posItlon 
Tape  Labels  Text 
Characters 

1 

1 

Command  Mach  Number 

Comnand  Y-pos1t1on 

1 

1 

1 

;  c 
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TABLE  3-13.  HUD  TAKEOFF/CRDISE  FORMAT  DYHAMICS  (Page  2  of  2) 


Symbol 

Controlling  Parameter 

Oynami cs 

Barometric 

0 

Pilot  Control 

Visibility 

Altitude  Scale 

Barometric  Attitude 

Tick  Marks  Y-posItlon 
Tape  Labels  Text 
Characters 

Connand  Attitude 

Command  Y-posItlon 

Radar  Altitude 

Pilot  Control 

Scale 

Radar  Attitude 

Tick  Marks  Y-posItlon 
Tape  Labels  Text 
Characters 

Command  Attitude 

Connand  Y-posItlon 

Aircraft  Reticle 

A1 rspeed 

Visibility 
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TABLE  3-14.  HUD  TRANSITION  FORMAT  DYNAMICS 


Symbol 

Controlling  Parameter 

Dynamics 

Velocity  Vector 

Roll,  Pitch,  True  Heading, 
North  Velocity,  East  Velo- 

Position 

. 

city.  Vertical  Velocity 

Breakaway 

TBO 

Visibility 

Warning  Indicator 

TBO 

Visibility 

Heading  Scale 

Pilot  Control 

Visibility 

Magnetic  Heading 

Tick  Marks  X-position 
Tape  Labels  Text 
Characters 

Command  Heading 

Coirmand  X>position 

Airspeed  Scale 

Pilot  Control 

Visibility 

True  Airspeed 

Tick  Marks  Y-position 
Tape  Labels  Text 
Characters 

Conmand  Airspeed 

Conmand  Y-position 

Barometric  Altitude 

Pilot  Control 

Visibility 

Scale 

Barometric 

Tick  Marks  Y-position 
Tape  Labels  Text 
Characters 

Command  Altitude 

Command  Y-position 

Radar  Altitude 

Pilot  Control 

Visibility 

Scale 

Radar  Altitude 

Tick  Marks  Y-position 
Tape  Labels  Text 
Characters 

Conmand  Y-position 

Angle  of  Attack 

Angle  of  Attack' 

Y-position 

Glides lope  Error 

61  ides lope  Error 

Y-position 

Localizer  Error 

Localizer  Error 

X-position 

TABLE  3-15.  HUD  LANDING  FORMAT  DYNAMICS 


Symbol 

1  Controlling  Parameters 

Dynamics 

Horizon  Line 

Pitch 

Y-position 

Auxiliary  Pitch 
Line 

Pitch 

Y-position 

Pitch  Labels  Text 

Characters 

Heading  Tick 

Magnetic  Heading 

Tick  Marks  X-position 

Heading  Text 

Magnetic  Heading 

Text  Characters 

Comnand  Heading 
Caret 

CoRoiand  Heading 

Comnand  X-positlon 

Vertical  Velocity 
Scale 

Vertical  Velocity 

TBD 

Tick  Marks  Y-position 
Comnand  Y-position 

Airspeed  Text 

True  Airspeed 

Text  Characters 

Command  Airspeed 
Diamond 

Command  Airspeed 

Y-position 

Barometric 
Altitude  Text 

Pilot  Control 

Baromatric  Altitude 

Visibility 

Text  Characters 

Radar  Altitude 
Text 

Pilot  Control 

Radar  Altitude 

Visibility 

Text  Characters 

Glldeslope  Error 
Bar 

Glldeslope  Error 

Y-posItlon 

Glldeslope  Angle 
Text 

Pilot  Control 

TBD 

Visibility 

Text  Characters 

Engine  Torque 

Text 

Pilot  Control 

TBD 

Visibility 

Text  Characters 

Wing  Angle 

Tick 

TBD 

Y-position 

Runway  Image 

TBD 

TBD 

Side  Slip 

Circle 

Side  slip 

X-posItlon 
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F16DRE  3“34  “  HMD  Honul  Format 
TABLE  3-16.  HMD  NORMAL  FORMAT  DYNAMICS 


Symbol 

Controlling  Parameters 

» 

Horizon  Line 

Helmet  roll  and  pitch 

Aircraft  pitch 

Position,  Rotation 

Pitch  Ladder 

Pilot  Control 

Helmet  roll  and  pitch 

Aircraft  roll  and  pitch 

Visibility 

Position,  Rotation 

Flight  Director 

Pilot  Control 

Helment  roll,  pitch. and  heading 
TBD 

Visibility 

Position 

Velocity  Vector 

Pilot  Control 

Helmet  roll,  pitch.and  heading 
Vertical  velocity 

North  Velocity.  East  Velocity 

Visibility 

Position 

Heading  Marks 

Pilot  Control 

Helmet  Heading 

Aircraft  heading 

Visibility 

Ticks  Marks  X-posItlon 

Text  Characters 

O 
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The  VSD  presents  two  formats:  a  Pitch  Ladder  format  and  a  Predictive  for¬ 
mat.  The  Pitch  Ladder  format  is  displayed  during  the  three  takeoff  modes:  the 
TRANSITION  mode,  the  CRUISE  mode,  and  the  SEARCH  mode.  The  format  presents  in¬ 
formation  similar  to  the  HUD  Takeoff /Cruise  format. 

The  Predictive  format  presents  a  perspective  representation  of  the  ground 
plane  and  the  predicted  aircraft  fll^t  path.  The  predictive  format  is  dis¬ 
played  during  the  TRANSITION  TO  LANDING  mode  and  during  the  three  landing  modes. 
Figures  3-35  and  3-36  illustrate  the  two  VSD  formats  and  Tables  3-17  and  3-18 
specify  the  format's  dynamics. 

The  HSD  shall  display  one  format  with  optional  content:  map  or  flight  plan. 
The  map  option  illustrated  in  Figure  3-37  shall  present  flight  status  informa¬ 
tion  and  an  optional  compass  rose  superimposed  on  a  map  defining  geographic  ter¬ 
rain  features.  Format  characteristics  Include:  communications,  target,  and 
map  scale  status  information  (top  region  of  display)  and  positional  status  and 
arrival  time  information  (lower  region  of  display).  The  fll^t  plan  option 
illustrated  in  Figure  3-38  shall  present  the  same  flight  status  information  as 
in  the  map  option  except  that  the  status  information  is  superimposed  onto  a 
flight  plan  rather  than  a  terrain  map.  Table  3-19  specifies  the  HUD  format 
d3mamlcs. 


3.4.15.3  Flight  Data  Display  Outputs 
Output 

ASSIGN  FORMAT  Parameters  HDD, 


Destination 
HMD,  VSD,  HSD 


Put  Procedure  Paraiaeters 
UPDATE  FORMAT  Parameters 

UPDATE  FORMAT  Parameters 

3.4.15.4  Flight  Data  Display 


(via  Graphics  Support) 

Graphics  Support 

HUD,  HMD,  VSD 

(via  Graphics  Support) 

HSD  (via  Graphics  Sup:- 
port) 

Special  Requirements 


Frequency 

Asynchronous 

60  Hz,  20  Hz,  5Hz 
60  Hz,  20  Hz 

5  Hz 


None. 

3.4.16  Equipment  Monitoring  Requirements 

The  Equipment  Ifonltorlng  function  provides  the  pilot  with  aircraft  and 
system  status  Information  through  the  maintenance  of  the  AIDS  SAD.  The  sources 
of  the  sensor  inputs  to  this  function  will  be  the  ULAIDS  and  lEIS. 

3.4.16.1  Equipment  Monitoring  Inputs 

The  inputs  to  Equipment  Monitoring  shall  include  the  status  of  all  equip¬ 
ment  on  the  aircraft.  This  status  shall  be  transmitted  to  AIDS  via  ULAIDS, 
lEIS,  and  SOSTEL.  The  equipment  to  be  monitored  by  AIDS  is  TBD. 
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FIGURE  3-36  -  VSD  Predictive  format 
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TABLE  3-17.  VSD  PITCH  LADDER  FORMAT  DYNAMICS 


Symbol 

Controlling  Parameters 

Dynami cs  • 

Velocity  Vector 

Roll.  Pitch,  True  Heading. 

Position 

North  Velocity.  East  Velo¬ 
city,  Vertical  Velocity 

Flight  Director 

TBO 

Position 

BreakaMay 

TBO 

Visibility 

Warning  Indicator 

TBD 

Visibility 

Horizon  Line 

Pitch,  Roll 

Position,  Rotation 

Pitch  Ladder 

Pilot  Control 

Position,  Rotation 

Pitch,  Roll 

Pitch  Labels  Text  Characters 

Visibility 

Heading  Scale 

Magnetic  Heading 

Tick  Marks  X-position 

Coomand  Heading 

Tape  Labels  Text  Characters 
Conmand  X-position 

Vertical  Velocity 

Pilot  Control 

Visibility 

Scale 

Vertical  Velocity 

Tick  Marks  Y-position 

TBO 

Tape  Labels  Text  Characters 
Command  X-position 

Airspeed  Scale 

Pilot  Control 

Visibility 

True  Airspeed 

Tick  Marks  Y-position 

Command  Airspeed 

Tape  Labels  Text  Characters 
Command  X-position 

Mach  Number 

Pilot  Control 

Visibility 

Scale 

Mach  Number 

Tick  Marks  Y-position 

Command  Mach  Number 

Tape  Labels  Text  Characters 
Conmand  Y-position 

Barometric  Altitude 

Pilot  Control 

Visibility 

Scale 

Barometric  Altitude 

Tick  Marks  Y-position 

Command  Altitude 

Tape  Labels  Text  Characters 
Command  Y-position 

Radar  Altitude 

Pilot  Control 

Visibility 

Radar  Altitude 

Ticks  Marks  Y-position 

Command  Altitude 

Tape  Labels  Text  Characters 
Command  Y-position 

Roll  Scale 

Roll 

Tick  Marks  X-position 

Angle  of  Attack 

Angle  of  Attack 

Tick  Mark  rotation 

Y-position 

Bracket 
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TABLE  3-18.  VSD  PREDICTIVE  FORMAT  DYNAMICS 


Symbol 

Controlling  Parameters 

Dynami cs 

Predicted  Flight 
Path 

TBD 

TBD 

Ground  Plane  Image 

TBO 

TBD 

Breakaway 

TBD 

Visibility 

Warning  Indicator 

TBO 

Visibility 

Heading  Scale 

Pilot  Control 

Magnetic  Heading 

Command  Heading 

Visibility 

Tick  Marks  X-position 

Tape  Labels  Text  Characters 
Command  X-position 

Vertical  Velocity 
Scale 

Pilot  Control 

Vertical  Velocity 

TBD 

Visibility 

Tick  Marks  Y-position 

Tape  Labels  Text  Characters 
Command  Y-position 

Airspeed  Scale 

Pilot  Control 

True  Airspeed 

Connand  Airspeed 

Visibility 

Tick  Marks  Y-position 

Tape  Labels  Text  Characters 
Command  Y-position 

Mach  Number 

Scale 

Pilot  Control 

Mach  Number 

Comnand  Mach  Number 

Visibility 

Tick  Marks  Y-position 

Tape  Labels  Text  Characters 
Command  Y-position 

Barometric  Altitude 
Scale 

Pilot  Control 

Barometric  Altitude 

Command  altitudd 

Visibility 

Tick  Marks  Y-position 

Tape  Labels  Text  Characters 
Command  Y-position 

Radar  Altitude 

Scale 

Pilot  Control 

Radar  Altitude 

Command  Altitude 

Visibility 

Tick  Marks  Y-position 

Tape  Labels  Text  Characters 
Command  Y-position 

Roll  Scale 

Roll 

Tick  Mark  X-position 
and  rotation 

^  2 
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TABLE  3-19.  HSD  FORMAT  DYNAMICS 


Symbol 

Controlling  Parameters 

Oynamics 

Terrain  Map 

TBO 

TBO 

Flight  Plan 

TBD 

TBO 

Compass  Rose 

Pilot  Input 

Pilot  Input 

Aircraft  Position 

Visibility 

Rotation 

Orientation  Rotation 

Aircraft  Position 

Pilot  Input 

Aircraft  Position 

Position 

Orientation  Rotation 

Comnunlcatlon 

Annotation 

TBO 

TBO 

Flight  Status 
Annotation 

TBO 

TBO 

The  Inputs  to  EqulpMQt  Monitoring  shall  also  Include  pilot  format  con¬ 
trol.  These  Inputs  are  listed  below. 


Input 

Source 

Frequency 

Checklist  Selection 

Pilot 

(via 

DPICS) 

Aperiodic 

Checklist  Cursor 
Advancement 

Pilot 

(via 

DPICS) 

Aperiodic 

Checklist  Page 
Advancement 

Pilot 

(via 

DPICS) 

Aperiodic 

Checklist  Page 

Backup 

Pilot 

(via 

DPICS) 

Aperiodic 

Engine  Start  Format 
Selection 

Pilot 

(via 

DPICS) 

Aperiodic 

Sensor  Failure 
Acknowledgement 

Pilot 

(via 

DPICS) 

Aperiodic 

Status  Format 

Selection 

Pilot 

(via 

DPICS) 

Aperiodic 

O 
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3.4.16.2  Equipment  Monitoring  Processing 


The  Equipment  Monitoring  function  shall  support  three  subfunctions:  check¬ 
list  Interrogation,  system  status  reporting,  and  engine  start  monitoring.  A 
common  data  base  which  contains  the  status  of  all  aircraft  equipment  shall  be 
maintained  In  the  performance  of  these  three  functions.  In  addition  to  equip¬ 
ment  status,  the  data  base  contains  a  specification  of  the  warning  and  caution 
limits  values  for  each  equipment,  a  specification  of  the  checklists  In  which 
each  equipment  appears,  and  a  specification  of  the  position  of  the  equipment 
In  the  aircraft  equipment  hierarchy  (l.e.,  to  which  system  and  subsystem  the 
equipment  belongs).  This  data  base  and  the  specification  of  the  corresponding 
checklists  and  system  status  formats  are  generated  by  the  AIDS  Equipment  Dis¬ 
play  Formatter  from  a  formal  specification  of  the  aircrafts'  equipment  hier¬ 
archy.  The  Equipment  Display  Formatter  Is  described  In  the  “AIDS  Operational 
Display  Software  Program  Performance  Specification"  (Roth  77).  The  remainder 
of  this  section  specifies  the  processing  required  for  the  three  Equipment  Moni¬ 
toring  subfunctions. 


Checklist  Processing  shall  allow  the  pilot  to  visually  Inspect  system  flight 
parameters  as  defined  by  the  specific  flight  operating  mode.  The  checklists 
shall  Include:  Interior  Inspection,  Briefing  Data  Entry,  Engine  Start,  Post 
Start,  Taxi,  Vertical  Takeoff,  Short  Takeoff,  Descent,  Vertical  Landing,  and 
Short  Landing.  A  checklist  format  shall  be  comprised  of  a  list  of  format  pages 
delineating  the  associated  sensors  and  values.  The  checklist  will  be  presented 
on  the  advisory  display  in  a  prescribed  sequential  order.  Checklist  Processing 
l(q>ut  responses  shall  provide  for  page  advancement  and  cursor  advancement. 

The  cursor  position  within  a  checklist  page  shall  Identify  to  the  pilot  a  sensor 
failure.  A  cursor  sdvancement  Input  response  shall  result  in  the  reposition  of 
the  cursor  to  the  next  failed  sensor  currently  presented  on  the  checklist  page. 
If  none  remains  within  the  existing  page,  page  advancement  shall  be  performed. 

A  page  advancement  Input  response  allows  the  pilot  to  bypass  an  Interrogation 
of  a  sensor  page  list;  In  response,  the  Equipment  Monitoring  function  shall 
display  the  next  page  within  the  sequential  checklist.  If  no  additional  pages 
remain  within  the  checklist,  processing  shall  so  Inform  the  pilot.  Checklist 
Processing  shall  also  allow  the  pilot  to  back  up  to  the  preceding  page.  The 
concent  and  format  of  the  checklists  are  TBD. 


The  System  Status  Reporting  function  utilizes  two  generic  formats:  Che 
Single  Status  List  format  and  Dual  Status  List  format.  These  are  Illustrated 
In  Figures  3-39  and  3-40.  Representative  examples  of  the  use  of  these  formats 
are  Illustrated  for  the  hydraulic  and  engine  subystems  In  Figures  3-41  and  3-42. 
The  Single  Status  List  format  contains  Che  name  of  Che  equipment  subsystem  being 
displayed  and  the  value  and  Che  In-tolerance/out-of-tolerance  prompt  for  each 
sensor  In  the  subsystem.  The  format  also  contains  an  Indication  of  Che  status 
of  the  ocher  aircraft  equipment  subsystems.  The  Dual  Status  List  formst  pre¬ 
sents  Che  same  Information  except  that  two  values  are  presented  for  each  sensor 
and  no  tolerance  prompt  Is  presented.  The  dual  list  is  used  for  duplicated 
subsystems  such  as  engines.  Table  3-20  specifies  Che  dynamics  of  the  system 
status  formats. 
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HYDRAULICS 
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aUlO  LEVEL 
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FIGURE  3-Al  -  Single  Status  List  Format  Example 
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TABLE  3-20,  STSTQI  STATUS  FOBHAT  DTNAHICS 


Symbol 

Controlling  Parameters 

Dynami cs 

System  Name 

Name  from  Equipment  Data  Base 

Text  Characters 

Sensor  Tolerance 
Prompt 

Sensor  Value 

Check  Symbol  Visibility 
Arrow  Symbol  Visibility 

Sensor  Value  Text 

Sensor  Value 

Text  Characters 

Sensor  Value 
Bargraph 

Sensor  Value 

Tick  X-posItlon 

Other  System  Text 

Other  Systems  Status 

Text  Characters 

Th«  specific  equlpaent  oonlcorlag  fonoats  are  TBD.  The  required  generic 
processing  for  the  systea  status  fimctlon  Is  discussed  In  the  following  para¬ 
graphs. 

In  response  to  the  periodic  sensor  Input  messages  from  the  ULAIDS  and  lEIS 
which  correspond  to  those  sensor  values  currently  being  displayed  on  the  ad¬ 
visory  display,  the  Equipment  Monitoring  function  shall  convert  each  sensor 
value  to  Its  Internal  AIDS  representations.  Bach  new  sensor  value  shall  be 
used  to  update  the  corresponding  sensor  value  field  of  the  existing  advisory 
display  format.  For  the  Single  Status  List  format,  the  present  value  and  tol¬ 
erance  prompt  symbols  shall  be  modified.  If  the  Dual  Status  List  format  is  be¬ 
ing  displayed,  the  corresponding  left  or  rl^t  present  value  fields  shall  be 
updated. 

Upon  the  detection  of  a  sensor  failure  occurrence,  the  ULAIDS  or  lEIS 
shall  transmit  (asynchronously)  to  Equipment  Monitoring  a  sensor  failure 
message.  In  response.  Equipment  Monitoring  shall  convert  the  sensor  value  to 
its  corresponding  AIDS  Internal  format  and  the  sensor's  current  value  and  asso¬ 
ciated  "failure  message"  shall  be  placed  In  a  failure  queue.  The  failure  mes¬ 
sage  shall  be  displayed  in  the  current  advisory  display  format's  "other  system" 
line  field. 

Sensor  Failure  Acknowledgement  Processing  allows  the  pilot  to  request  from 
the  Equipment  Monitoring  function  the  presentation  of  detailed  Information 
describing  a  sensor  failure  occurrence.  The  presentation  of  sensor  failure  in¬ 
formation  corresponds  to  the  display  of  a  new  format  as  defined  by  the  exist¬ 
ing  "active"  entry  In  the  failure  queue.  The  "active  entry"  In  the  failure 
queue  will  correspond  to  the  "active  failure  message"  currently  presented  on 
the  advisory  displays.  In  response  to  failure  acknowledgement,  the  new  display 
format  and  sensor  requirements  shall  be  established  and  sampling  of  the  asso¬ 
ciated  sensor  values  shall  be  subsequently  requested  from  the  ULAIDS  and  lEIS. 
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^  Format  change  processing  shall  allow  the  pilot  to  explicitly  designate 
i§  new  format  requirements  to  the  Equipment  Monitoring  function*  Analogous  to 
the  failure  acknowledgement  process,  the  new  display  format  and  sensor  re¬ 
quirements  shall  be  established  and  sampling  of  the  associated  sensor  values 
shall  subsequently  be  requested  from  the  ULAIDS  and  ISIS* 

The  third  function  of  Equipment  Monitoring  Is  engine  start  monitoring. 

This  function  displays  the  Engine  Start  format  Illustrated  In  Figure  3-43. 

The  Engine  Start  format  Is  displayed  automatically  after  completion  of  the 
Engine  Start  Checklist  Processing  or  In  response  to  an  explicit  pilot  request. 
The  format  contains  a  vertical  bargraph  Indicating  the  current  value  of  each 
engine's  RPM;  a  text  string  also  displays  the  RPM  value.  Table  3-21  specifies 
the  Engine  Start  format's  dynamics. 

3.4.16.3  Equipment  Monitoring  Output 


Output 


Destination 


Frequency 


ASSIGN  FORMAT  Parameters 


SAD  (via  Graphics  Support)  Aperiodic 


Put  Procedure  Parameters 


Graphics  Support 


UPDATE  FORMAT  Parameters 


SAD  (via  Graphics  Support)  5  Hz 


3.4.17  Communications  Data  Display  Requirements 


I  The  Communications  Data  Display  function  Is  responsible  for  Informing  the 
pilot  of  the  assignments  of  the  communications  equipment.  The  COMM  external 
avionics  subsystem  supplies  the  Inputs  to  Communications  Data  Display. 

3.4.17.1  Comsninlcatlons  Data  Display  Inputs 


Input 

Source 

Frequenc; 

UHF  1  on/off 

COMM 

5  Hz 

OHF  1  channel 

COMM 

5  Hz 

UHF  I  frequency 

COMM 

5  Hz 

UHF  2  on/off 

COMM 

5  Hz 

UHF  2  channel 

COMM 

5  Hz 

UHF  2  frequency 

COMM 

5  Hz 

VHF  on/off 

COMM 

5  Hz 

VHF  channel 

COMM 

5  Hz 

VHF  frequency 

COMM 

5  Hz 

IFF  on/off 

COMM 

5  Hz 

IFF  Mode  1  on/off 

COMM 

5  Hz 

IFF  Mode  1  code 

COMM 

5  Hz 

IFF  Mode  2  on/off 

COMM 

5  Hz 

IFF  Mode  2  code 

COMM 

5  Hz 

IFF  Mode  3/A  on/off 

COMM 

5  Hz 

IFF  Mode  3/A  Code 

COMM 

5  Hz 
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Input 

Source 

Frequency 

IFF  Mode  3/C  on/off 

COMM 

5  Hz 

IFF  Mode  3/C  Code 

COMM 

5  Hz 

IFF  Mode  4  on/off 

COMM 

5  Hz 

IFF  Mode  4  Code 

COMM 

5  Hz 

Radar  Beacon  on/off 

COMM 

5  Hz 

Radar  Beacon  Code 

COMM 

5  Hz 

3.4.17.2  Conmmnlcatlona  Data  Display  Processing 

When  activated  by  an  explicit  pilot  request  for  the  COMM  format.,  Communi¬ 
cations  Data  Display  shall  display  the  COMM  format  Illustrated  In  Figure  3-A4 
on  either  the  LSAD  or  RSAD.  The  format  shall  be  updated  at  5  Hz.  The  dynamics 
of  the  CGMM  format  are  specified  In  Table  3-22. 


3.4.17.3  Communications  Data  Display  Outputs 

Output  Destination 


Frequency 


ASSIGN  FORMAT 

Parameters 

SAD  (via  Graphics 

Support) 

Aperiodic 

Put  Procedure 

Parameters 

Graphics  Support 

5  Hz 

UPDATE  FORMAT 

Parasieters 

SAD  (via  Graphics 

Support) 

5  Hz 

^  3.4.17.4  Communications  Data  Display  Special  Requirements 


None. 

3.4.18  ASW  Display  Requirements 

The  ASW  display  requirements  are  TBD. 

3.4.19  AEW  Display  Requirements 

The  AEW  display  requirements  are  TBD. 

3.5  ADAPTATION 

This  section  describes  the  configuration  parameters  and  the  resource  re¬ 
quirements  of  the  AIDS  software.  The  configuration  parameters  are  those 
complle-tlme  or  system-time  values  that  allow  the  AIDS  software  to  be  con¬ 
figured  to  satisfy  different  mission  requirements.  The  resource  requirements 
are  for  primary  memory,  secondary  storage,  and  processor  throughput. 

3.5.1  AIDS  Configuration  Control 


t 


This  section  specifies  the  AIDS  software  configuration  parameters.  The 
required  ability  to  configure  the  AIDS  software  Is  discussed  here,  first  In 
terms  of  specifying  an  approach  to  AIDS  program  generation  that  will  ensure 
system  flexibility,  and  then  In  terms  of  the  specific  configuration  parameters. 
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COMM  STATUS 


CHAN 

FREO 

CMD  UHF" 

ON 

1 

387.1 

VHF/FM 

OFF 

2 

133.8 

ADF/AUX  UHF 

ON 

3 

275.6 

MODE 

PWR 

CODE 

IFF 

ON 

1 

ON 

05 

2 

ON 

3/A 

ON 

5363 

3/C 

ON 

0220 

4 

ON 

B 

RADAR  BCN 

ON 

DOUBLE 

3 

FIGURE  3-44  -  COMM  Format 
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TABLE  3-22.  COMM  FORMAT  DYNAMICS 


Symbol 

Controlling  Parameters 

Dynamics 

UHF  1  on/off  text 

UHF  1  on/off 

Text  Characters 

UHF  1  channel  text 

UHF  1  channel 

Text  Characters 

UHF  1  frequency  text 

UHF  1  frequency 

Text  Characters 

UHF  2  on/off  text 

UHF  2  on/off 

Text  Characters 

UHF  2  channel  text 

UHF  2  channel 

Text  Characters 

UHF  2  frequency  text 

UHF  2  frequency 

Text  Characters 

VHF  on/off  text 

VHF  on/off 

Text  Characters 

VHF  channel  text 

VHF  channel 

Text  Characters 

VHF  frequency  text 

VHF  frequency 

Text  Characters 

IFF  on/off  text 

IFF  on/off 

Text  Characters 

IFF  Mode  1  on/off  text 

IFF  Mode  1  on/off 

Text  Characters 

IFF  Mode  1  code  text 

IFF  Mode  1  code 

Text  Characters 

IFF  Mode  2  on/off  text 

IFF  Mode  2  on/off 

Text  Characters 

IFF  Mode  2  code  text 

IFF  Mode  2  codd 

Text  Characters 

IFF  Mode  3/A  on/off  text 

IFF  Mode  3/A  on/off 

Text  Characters 

IFF  Mode  3/A  code  text 

IFF  Mode  3/A  code 

Text  Characters 

IFF  Mode  3/C  on/off  text 

IFF  Mode  3/C  on/off 

Text  Characters 

IFF  Mode  3/C  code  text 

IFF  Mode  3/C.icode 

Text  Characters 

IFF  Mode  4  on/off  text 

IFF  Mode  4  on/off 

Text  Characters 

IFF  Mode  4  code  text 

IFF  Mode  4  code 

Text  Characters 

Radar  Beacon  on/off  text 

Radar  Beacon  on/off 

Text  Characters 

Radar  Beacon  code  text 

Radar  Beacon  code 

Text  Characters 

3. 5. 1.1  AIDS  Prograa  Generation 


This  section  discusses  the  flexibility  requirements  for  the  AIDS  soft- 
tnre,  and  the  design  presented  In  Sections  3.3.5  and  3.4  satisfies  these 
requirements. 

Achieving  the  goals  of  system  flexibility  for  AIDS  Is  complicated  by  the 
need  for  efficiency.  The  AIDS  software  must  be  capable  of  processing  a  large 
volume  of  Inputs  each  second.  It  must  achieve  this  throughput  within  a  hard¬ 
ware  configuration  that  does  not  severely  Impact  aircraft  size  and  weight  re¬ 
strictions. 

Two  techniques  are  used  to  meet  the  efficiency  and  flexibility  require¬ 
ments  of  the  AIDS  software.  These  are  data-driven  algorithms  and  off-line 
data  base  preparation.  These  two  techniques  are  tightly  coupled.  The  second 
cannot  be  utilized  without  the  first. 

Data-driven  algorithms  provide  both  efficiency  and  flexibility  advantages. 
The  efficiency  advantages  are  primarily  In  the  area  of  reduced  memory  require¬ 
ments.  Instead  of  repeatir.g  code  for  each  Instance  of  a  function,  a  single 
generic  function  is  used.  Instantiated  each  time  by  the  information  contained 
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within  the  data  base*  The  use  of  data-driven  algorithms  provides  added  flex¬ 
ibility.  Since  Information  Is  contained  within  data  bases  as  opposed  to  ma¬ 
chine  code,  a  great  amount  of  dynamic  flexibility  Is  Introduced.  If  one  pro¬ 
cess  wishes  to  alter  the  execution  of  another.  It  simply  requires  access  to 
the  latter's  data  base. 

Off-line  data  base  preparation  has  significant  Impact  on  both  the  flex¬ 
ibility  and  efficiency  of  the  AIDS  software.  Through  the  use  of  off-line  pro¬ 
cessors  and  compilation  macros,  the  system's  flexibility  Is  greatly  enhanced 
with  no  efficiency  losses.  In  fact,  the  use  of  off-line  preprocessors  can 
lead  to  efficiency  gains. 

A  prime  example  of  the  desirability  of  off-line  processors  can  be  found 
In  the  Equipment  Display  Formatter.  Each  new  system  Included  In  V/STOL  will 
contain  a  new  set  of  aircraft  sensors.  When  the  Equipment  Display  Formatter 
Is  used,  each  new  set  of  sensors  may  be  quickly  defined  and  compiled  Into  the 
appropriate  Equipment  Monitoring  data  bases  with  very  little  Impact  on  the 
AIDS  ODS.  In  addition,  the  use  of  the  Equipment  Display  Formatter  will  facili¬ 
tate  human  factors  analysis  by  permitting  easy  modification  of  the  system 
monitoring  formats. 

Probably  the  most  Important  aid  to  human  factors  analysis  will  be  the  AIDS 
Display  Formatter.  This  tool  will  permit  frequent  and  complex  display  changes 
to  be  made  quickly  and  easily.  In  addition,  through  the  rapid  change  mech¬ 
anism,  extremely  efficient  display  update  code  can  be  generated. 

The  Standard  AIDS  Display  Interface  (SADI)  will  be  fundamental  to  achieving 
the  required  flexibility.  Standardization  of  the  display  command  language  en¬ 
sures  ability  to  mix  and  match  displays.  One  can  easily  add  new  displays  and 
exchange  the  functions  of  present  displays. 

Compilation  macros  shall  be  used  In  several  places  within  the  AIDS  soft¬ 
ware.  For  example,  the  Information  pertaining  to  Flight  Data  Display  input 
parameters  (l.e.,  source,  priority,  alternates,  and  flight  data  base  para¬ 
meter  to  update)  shall  be  declared  using  macros.  This  shall  facilitate  the 
addition  of  new  Input  parameters.  In  general,  whenever  several  data  bases 
contain  Information  pertaining  to  a  set  of  parameters,  this  Information  shall 
be  defined  using  compilation  macros. 

Another  place  where  macros  shall  be  used  Is  In  the  Insertion  of  debugging 
and  performance  monitoring  code.  This  will  provide  the  ability  to  easily  In¬ 
sert  and  delete  this  code.  It  shall  also  create  a  uniform  debugging  Inter¬ 
face  and  simplify  the  design  of  the  data  processor  debugging  communications. 

An  Important  flexibility  aspect  of  the  design  presented  In  this  specifica¬ 
tion  Is  the  functional  division  of  the  software.  This  division,  as  opposeu  ^o 
one  along  the  lines  of  physical  displays,  is  superior  In  terms  of  software 
flexibility.  Each  ODS  subsystem  (Flight  Data  Display,  Equipment  Monitoring, 
Comnunication  Data  Display,  ASW  Display,  and  AEW  Display)  Is  specified  so  that 
all  physical  display  dependencies  are  encapsulated  In  the  display  update  rou¬ 
tines.  This  permits  new  displays  to  be  added,  simply  by  addition  of  a  corre¬ 
sponding  display  routine.  As  long  as  Information  processing  requirements  remain 
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unchanged,  the  existing  software  need  not  be  modified.  This  would  permit,  for 
example,  the  easy  expansion  of  AIDS  to  service  additional  operator  stations. 

3. 5. 1.2  AIDS  Configuration  Parameters 

The  AIDS  configuration  parameters  are  TBD. 

3.5.2  AIDS  Resource  Requirements 

The  AIDS  system  resource  requirements  are  specified  In  three  subsections: 
Primary  Memory  Requirements,  Secondary  Memory  Requirements,  and  Throughput  Re¬ 
quirements.  The  "Standard  Reserve  Capacity  Requirements  for  Digital  Combat 
System  Processors"  (Navy  72)  requires  that,  for  program  acceptance,  a  program 
must  have  a  20-percent  reserve  for  Its  resource  requirements.  The  require¬ 
ments  listed  below  Include  this  reserve.  For  program  acceptance,  this  reserve 
may  not  be  utilized. 

3. 5. 2.1  AIDS  Primary  Memory  Requirements 

Listed  below  are:  first,  the  primary  memory  requirements  for  SDEX/M  and 
the  19  AIDS  functions;  and  second,  the  corresponding  primary  requirements  for 
the  AIDS  software  In  each  of  the  four  data  processor  configurations  described 
In  Section  3.2.1.  Tabel  2-23  lists  the  memory  requirements  by  function  and 
Tables  3-24  through  3-27  list  the  memory  requirements  of  each  data  processor. 

3. 5. 2. 2  AIDS  Secondary  Memory  Requirements 

Each  AIDS  mass  memory  must  be  capable  of  containing  all  the  AIDS  softwartt 
and  firmware,  all  the  ICP  configuration  tables,  all  the  format  SADI  prograaw 
and  update  tables,  and  the  files  written  during  the  mission.  The  required  num¬ 
ber  of  words  for  all  of  this  data  is  listed  In  Tables  3-28  and  3-29  for  the 
ASV  and  AEW  systems. 

3.5.3  AIDS  Throughput  Requirements 

The  throughput  requirements  defined  here  are  those  required  for  the  per¬ 
iodic  display  updates.  The  requirements  do  not  explicitly  Include  the  re- 
<iulrements  for  aperiodic  processing,  namely  ICP  switch  processing  and  mission 
mode  changes.  The  throughput  requirements  are  calculated  by  adding  an  esti¬ 
mate  for  operating  system  overhead  to  the  basic  computation  tlioe  required  for 
a  display  update.  This  estimate  is  20  percent  of  the  basic  computation  time. 
Computation  Is  expressed  as  the  percentage  of  the  potential  throughput  of  an 
AN/ATK-14  conflgtired  with  an  Extended  Arithmetic  Unit.  Table  3-30  lists  the 
throughput  requirements  of  the  Data  Processor  1  (pilot)  configuration. 
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TABLE  3-23.  AIDS  FUNCTION  PRIMARY  MEMORY  REQUIREMENTS 


AIDS  Function 

Instruction  Words 

Data  Words 

SDEX/M 

5,700 

2,000 

I/O 

4,500 

1,500 

File  Systen 

4,500 

1,500 

Performance  Monitoring 

2,600 

500 

System  Initialization 

2,600 

200 

Reconfiguration 

4,500 

500 

Overlay 

2,600 

200 

BIED 

500 

500 

Switch  Processing 

3,000 

3,000 

Force  Stick  Processing 

500 

100 

HOTAS 

TBD 

TBD 

Graphics  Support 

3,000 

1,000 

Voice  Synthesis 

TBD 

TBD 

Voice  Input 

TBD 

TBD 

Voice  Recognition 

TBD 

TBD 

Flight  Data  Display 

15,000 

6,000 

Equipment  Monitoring 

9,000 

10,000 

Communication  Data  Display 

500 

1,000 

ASW  Display 

TBD 

TBD 

AEW  Display 

TBD 

TBD 
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TABLE  3-24.  PRIHART  MEMORY  REQUIREMENTS  DATA  PROCESSOR  1  (PILOT) 


AIDS  Function 

Instruction  Uords 

Data  Words 

SDEX/M 

5,700 

2,000 

AIDS  OS 

21,300 

3,400 

BIED 

500 

500 

Switch  Processing 

3,000 

3,000 

Force  Stick  Processing 

500 

100 

HOTAS 

TBD 

TBD 

Voice  Recognition 

TBD 

TBD 

Graphics  Support 

3,000 

1,000 

Voice  Synthesis 

TBD 

TBD 

Video  Input 

TBD 

TBD 

Flight  Data  Display 

15,000 

6,000 

Equipment  Monitoring 

9,000 

10,000 

Communication  Data  Display 

500 

1,000 

Subtotal 

58,500  +  TBD 

27,000  +  TBD 

+  20  X 

11,700  +  TBD 

5,400  +  TBD 

TOTAL 

70,200  +  TBD 

32  ,.400  +  TBD 
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TABLE  3-25.  PRIMARY  MEMORY  REQUIREMENTS  FOR  ASW  CATA  PROCESSOR  2 


AIDS  Function 

Instruction  Words 

Data  Words 

SDEX/M 

5,700 

2,000 

AIDS  OS 

21,300 

3,400 

Graphics  Support 

3,000 

1,000 

Video.  Input 

TBD 

TBD 

Flight  Data  Display 

15,000 

6,000 

ASW  Display 

TBD 

TBD 

Subtotal 

45,000  +  TBD 

12,400  '4'  TBD 

-1-  20  Z 

9,000  +  TBD 

2,500  +  TBD 

TOTAL 

54,000  +  TBD 

lA^SOO  +  TBD 

TABLE  3-26.  PRIMARY  MEMORY  REQUIREMENTS  FOR  ASW  DATA  PROCESSOR 


3 


4 


AIDS  Function 

Instruction  Words 

Data  Words 

SDEX/M 

5,700 

2,000 

AIDS  OS 

21,300 

d,400 

Switch  Processing 

3,000 

3,000 

Force  Stick  Processing 

500 

100 

Graphics  Support 

3,000 

1,000 

Video  Input 

TBD 

TBD 

ASW  Display 

TBD 

TBD 

Subtotal 

33,500  +  TBD 

9,500  -1-  TBD 

+  20  Z 

6,700  +  TBD 

1,900  +  TBD 

TOTAL 

40,200  +  TBD 

11,400  +  TBD 
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TABUB  3-27.  FRIMARY  MEMORY  REQEYRRMEMTS  FOR  AEU  DATA  FROCESSOR  2  (MISSION) 


AIDS  Function 

Instruction  Words 

Data  Words 

SDEX/M 

5,700 

2,000 

AIDS  OS 

21,300 

3,400 

Switch  Processing 

3,000 

3,000 

Force  Stick  Processing 

500 

100 

Graphics  Support 

3,000 

1,000 

Video  Input 

TBD 

TBD 

Flight  Data  Display 

15,000 

6,000 

AEW  Display 

TBD 

TBD 

Subtotal 

48,500  +  TBD 

15,500  TBD 

+  20  X 

9,700  +  TBD 

3.100  +  TBD 

TOTAL 

58,200  +  TBD 

18,600  -f  TBD 
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TABLE  3-28.  MASS  MEMORY  REQUIREMENTS  FOR  ASW  SYSTEM 


Data 

Number  of  Words 

AIDS  Software 

60,000  +  TBD 

AIDS  Firmware 

-100,000 

Pilot  I CP  Tables 

MPICS 

4,000 

DPICS 

2,000 

TACCO  ICP  Tables 

MPICS 

-3,000 

DPICS 

-1 ,500 

SENSO  ICP  Tables 

MPICS 

-3,000 

DPICS 

-1 ,500 

Flight  Data  Formats 

SADI  Programs 

5,000 

Update  Tables 

5,000 

Equipment  Monitoring  Formats 

TBD 

Communication  Data  Formats 

SADI  Programs 

300 

Update  Tables 

300 

ASW  Data  Formats 

TBD 

6IED  Data  Files 

TBD 

LOG  File 

5,000 

Subtotal 

196,000  +  TBD 

+  20* 

39,000  +  TBD 

TOTAL 

235,000  *  TBD 
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TABLE  3-29.  KASS  MEMORT  REQUIREMENTS  FOR  AEW  SYSTEM 


Data 

Number  of  Words 

AIDS  Softwart 

60,000  +  TBD 

AIDS  Flnnware 

-100,000 

Pilot  I CP  Tables 

MPICS 

4,000 

DPICS 

2,000 

Cl CD  1 CP  Tables 

MPICS 

-3,000 

DPICS 

-1 ,500 

ACO  ICP  Tables 

MPICS 

-3,000 

DPICS 

-1 ,500 

Flight  Data  Formats 

SADI  Programs 

5,000 

Update  Tables 

5,000 

Equipment  Monitoring  Formats 

TBD 

CoBPuni cations  Data  Formats 

SADI  Programs 

300 

Update  Tables 

300 

AEW  Data  Foneats 

TBD 

DIED  Data  Files 

TBD 

LOG  File 

5,000 

Subtotal 

196,000  <«■  TBD 

*  20« 

39,000  TBD 

TOTAL 

235,000  +  TBD 
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TABLE  3-30.  DATA  PROCESSOR  1  (PILOT)  THROUGHPUT  REQUIREMENTS 


AIDS  Function 

Required  Throughout 

Flight  Data  Display 

30* 

Equipment  Monitoring 

20* 

Display  Update  Total 

50* 

20*  OSS  Overhead 

10* 

Subtotal 

60* 

20*  Reserve 

12* 

TOTAL 


72* 
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SECTION  4 
QUALITY  ASSURANCE 


4.1  GENERAL 

This  section  defines  the  testing,  documentation,  and  techniques  which  shall 
be  used  to  ensure  that  the  AIDS  software  meets  the  specifications  listed  In 
Section  3.  This  section  also  defines  the  AIDS  software  acceptance  test  crite¬ 
ria. 


Four  levels  of  program  testing  shall  be  used  during  the  development  of  the 
AIDS  software:  function,  program  performance,  system  Integration,  and  accept¬ 
ance.  Each  of  these  levels  Is  described  separately  in  the  following  paragraphs. 

Function  Testing  shall  verify  the  correctness  of  algorithms.  This  testing 
shall  address  two  questions:  first,  does  the  algorithm  Itself  work  In  the 
abstract,  and  second.  Is  the  algorithm  properly  stated  In  the  program  code? 

In  addition.  Function  Testing  shall  be  used  to  collect  estimates  on  memory 
requirements  and  timing  statistics.  This  Information  shall  be  monitored  from 
the  beginning  In  order  to  anticipate  problems  and  give  early  feedback  to  both 
software  and  hardware  designers.  The  estimates  shall  be  updated  continuously 
throughout  testing  to  provide  an  Increasingly  more  detailed  picture  of  soft¬ 
ware  performance. 

Program  Performance  Testing  shall  address  the  Integration  of  software  units 
which  were  tested  Individually  during  Function  Testing.  These  units  shall  be 
Integrated  to  produce  the  major  programs  of  the  AIDS  software,  namely  the  OSS, 
ODS,  and  DPICS.  Program  Performance  Testing  shall  be  directed  at  the  testing 
of  Interfaces,  both  software-to-software  Interfaces  and  sof tware-to-hardware 
Interfaces.  An  additional  goal  of  Program  Performance  Testing  shall  be  to  up¬ 
date  memory  requirements  and  timing  statistics. 

Systems  Integration  Testing  shall  address  the  Integration  of  the  complete 
software  and  hardware  laboratory  system.  It  shall  be  the  last  level  of  testing 
prior  to  the  Acceptance  Demonstration.  Testing  shall  Include  checkout  of  re¬ 
configuration  slttiatlons.  In  addition  to  exhaustive  testing.  Systems  Integra¬ 
tion  Testing  shall  also  involve  performance  tuning  of  some  software  algorithms. 

The  Software  Acceptance  Test  Is  a  demonstration  of  a  representative  sample 
of  the  total  operational  capabilities  of  the  AIDS  software.  An  Independent 
Hardware  Acceptance  Test  Is  assumed  to  have  been  performed  successfully  prior 
to  the  Software  Acceptance  Tests.  The  Software  Acceptance  Test  shall  demon¬ 
strate:  use  of  the  AIDS  Display  Formatter  for  off-line  preparation  of  display 
software  components;  use  of  the  AIDS  Command  Formatter  for  off-line  preparation 
of  ICS  software  components,  management  of  and  response  to  sensor  data  Input, 
aanagement  of  and  response  to  laisslon  data  Input,  management  of  and  response  to 
crew  input,  display  control,  diagnosis  of  and  recovery  from  faults,  adaptation 
to  failure  situations,  and  graceful  degradation  In  the  presence  of  Irrecoverable 
failures. 
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For  each  of  the  above  testing  levels,  a  separate  test  plan  shall  be  pre¬ 
pared.  Additionally,  test  specifications  and  reports  shall  be  prepared  as 
part  of  the  deliverable  AIDS  software  data  base.  Finally,  test  procedures 
shall  be  prepared  for  the  acceptance  test. 

The  following  two  subsections  describe  the  requirements  for  all  testing 
levels  and  the  acceptance  test  criteria. 

4.2  TEST  REQUIREMENTS 

This  section  describes  for  the  Function,  Program  Performance,  and  System 
Integration  Testing  levels,  the  tools  and  techniques  to  be  used.  The  tools 
and  techniques  are  discussed  according  to  level  and  then  according  to  the  major 
programs  of  the  AIDS  software. 

The  same  hardware  and  software  tools  are  required  for  both  Function  and 
Program  Performance  Testing.  For  these  levels  of  testing,  the  AIDS  software 
shall  be  tested  through  the  use  of  an  AN/A7R-14,  a  MIDER  simulator,  and  a  dis¬ 
play  simulator.  The  two  latter  hardware  modules  will  presumably  be  a  commercial 
minicomputer  and  a  commercial  Interactive  display  device.  The  AIDS  software 
shall  be  developed  through  the  Facility  for  Automated  Software  Production  (FASP) 
and  will  reside  In  FASP  data  bases,  as  will  the  test  procedures  and  test  data. 
FASP  la  described  In  the  "FASP  Software  Production  and  Maintenance  Methodology" 
(Boyd  78).  Note  that  with  the  exception  of  the  AN/ATK-14,  Function  and  Program 
Performance  Testing  Is  quite  Independent  of  the  actual  AIDS  hardware.  This  Is 
Intended  to  restrict  the  uncertainty  In  the  testing  situation  to  the  software 
alone.  In  terms  of  required  software  tools.  Function  and  Program  Performance 
Testing  require  the  AIDS  FASP,  the  HOL  debugger  for  CMS-2M,  and  the  MIDER  dis¬ 
play  simulation  software. 

For  Function  and  Program  Testing,  all  test  Input  shall  be  hand-generated 
data  stored  In  the  FASP  data  base.  Because  the  data  Is  hand-generated,  there 
Is  no  Intention  to  make  Function  Testing  truly  exhaustive.  Function  Testing 
shall  be  directed  at  exercising  the  main-line  capabilities  of  the  units  being 
tested;  this  can  be  monitored  using  the  path  analysis  (trace)  feature  of  the 
HOL  debugger. 

The  test  outputs  shall  be  hand-checked  for  correctness.  Once  this  has  been 
done,  they  shall  be  recorded  In  the  FASP  data  base  as  a  standard  against  which 
new  test  results  can  be  automatically  compared  for  detection  of  side-effects. 
Such  recording  of  test  results  will  be  delayed  until  the  modules  have  reached 
a  steady  state  of  development,  at  which  time  the  test  results  are  also  In  a 
steady  state. 

For  System  Integration  Testing,  the  full  set  of  support  software  will  be 
employed.  This  Includes  FASP,  the  HOL  debugger,  the  CMS-2M  compiler,  the 
FORTRAN  compiler,  the  cross-assembler,  the  Performance  Monitoring  function  of 
the  OSS,  and  a  Data  Reduction  program. 

The  hardware  configuration  will  Include  the  NADC  Central  Computer  System 
(CCS)  B  machine  In  dedicated  real-time  with  the  AIDS  hardware  and  an  Integra¬ 
tion  minicomputer.  The  off-line  execution  of  the  Display  Formatter  and  the 
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Conmand  Formatter  will  take  place  on  the  CCS,  but  not  In  real-time  dedicated 
mode.  Compilations  and  preparation  of  load  tapes  through  FASF  will  take  place 
on  the  CCS  machine  where  the  FASF  data  bases  reside. 

Fll^t  scenarios  shall  be  generated  by  hand  for  a  variety  of  complete  mis¬ 
sions  and  mission  modes;  these  scenarios  form  the  Input  to  a  V/STOL  Simulator, 
which  executes  on  the  CCS  B  machine.  The  simulator's  output  Is  the  realistic 
data  stream  which  forms  the  Input  to  the  AIDS  software.  The  V/STOL  Simulator 
will  provide  for  the  nondetermlnlstlc  generation  of  hardware  faults  and  fail¬ 
ures  both  within  the  AIDS  hardware  and  outside  the  AIDS  hardware  (In  the  ex¬ 
ternal  avionics  subsystems).  This  is  the  mechanism  which  reconfiguration 
behavior  will  be  tested. 

Output  from  these  tests  will  come  from  several  sources.  The  Data  Recorder 
output  will  be  processed  by  a  Data  Reduction  program  resident  In  the  CCS.  This 
will  be  the  main  source  of  hardcopy  recorded  test  output  Information.  In  addi¬ 
tion,  use  of  the  Debugger  will  produce  memory  listings  which  are  processed  and 
printed  In  symbolic  form;  this  capability  will  be  available  for  detailed  ex¬ 
amination  of  Internal  program  snapshots.  The  visual  Images  produced  dynamically 
on  the  AIDS  displays  will  also  be  an  Important  part  of  the  test  results;  visual 
Inspection  of  the  display  behavior  Is  an  essential  part  of  monitoring  a  test. 

System  Integration  Testing  analysis  will  be  directed  at  three  considera¬ 
tions:  software  functional  behavior,  software  performance,  and  hardware  be¬ 
havior.  Test  analysis  of  software  functional  performance  will  be  directed  at 
determining  whether  or  not  the  correct  processing  has  been  applied  to  the  test 
Inputs.  (Tonconforming  functional  behavior  can  be  handled  Internally  within  the 
software  staff.  Test  analysis  of  software  performance  will  be  directed  at 
Identifying  exceptions  to  timing  and  memory  requirements,  or  potential  sources 
of  Improvements  In  timing  and  memory  characteristics.  Such  analysis  can  have 
both  software  and  hardware  Implications.  Test  analysis  of  hardware  behavior 
will  be  directed  at  Identifying  any  actual  or  potential  aberrant  hardware  be¬ 
havior  during  a  test.  This  completes  the  description  of  the  testing  method¬ 
ology  for  each  testing  level.  Discussed  below  is  the  particular  methodology 
to  be  used  for  each  of  the  major  AIDS  software  programs. 

The  testing  of  the  OSS  shall,  at  each  level,  validate  each  capability 
listed  below  In  Section  4.3  as  acceptance  test  criteria.  An  extremely  criti¬ 
cal  part  of  OSS  testing  Involves  OSS  response  to  hardware  or  software  errors 
and  to  hardware  failures.  All  single-point  failures  shall  be  generated  during 
testing.  Additionally,  multiple-point  failures  shall  also  be  generated  to  de¬ 
termine  that  the  AIDS  OSS  provides  the  maximum  possible  configuration.  At 
each  level  of  testing,  the  primary  and  mass  memory  storage  load  maps  and  the 
Ferformance  Monitoring  function  shall  be  used  to  verify  that  the  AIDS  OSS 
meets  the  resource  requirements  defined  In  Section  3.5.2. 

Testing  of  DFICS  shall  utilize  a  standard  ACOL  test  program,  an  MFICS 
simulator,  an  MFICS  output  recording  utility,  and  a  force-stlck-value  plot 
utility.  The  standard  ACOL  program  will  contain  at  least  one  utilization 
of  each  ACOL  capability.  The  required  hardware  facilities  are  the  CSS  com¬ 
puters,  the  AN/A7K-14,  the  MIDER  simulator,  the  display  simulator  and,  for 
Systems  Integration  Testing,  the  complete  AIDS  hardware  suite. 
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DPICS  testing  shall,  at  each  level,  validate  all  the  capabilities  which 
are  listed  below  as  acceptance  test  criteria*  Additionally,  testing  shall 
analyze  the  DPICS  response  to  random  command  Inputs,  erratic  force  stick  values, 
excessively  high  command  Input  frequency,  and  erroneous  rarameters.  A  standard 
Interaction  scenario  will  be  used  to  test  Command  Processing,  Force  Stick  Pro¬ 
cessing,  and  HOTAS  Processing.  The  scenario  will  utilize  all  the  capabilities 
contained  In  the  standard  ACOL  test  program.  At  each  level  of  testing,  the 
primary  and  mass  memory  storage  load  maps  and  the  Performance  Monitoring  func¬ 
tion  shall  be  used  to  verify  that  DPICS  meets  the  capacity  requirements  defined 
In  Section  3.5.2. 

Testing  of  the  ODS  shall  utilize  two  standard  flight  scenarios  (each  de¬ 
fined  as  a  set  of  crew  actions  and  a  Mission  Preparation  System  specification), 
a  standard  equipment  definition  specification,  the  V/STOL  Simulator,  and  a  set 
of  ADF-generated  displayed  formats.  The  two  standard  fll^t  scenarios  shall. 

In  combination,  exercise  all  display  formats  and  each  symbol  within  each  for¬ 
mat.  The  Equipment  Monitoring  teat  program  will  contain  at  least  one  utiliza¬ 
tion  of  each  Equipment  Monitoring  feature.  The  Mission  Preparation  System 
specification  shall  exercise  all  the  features  of  BIED  Input  and  shall  cause  all 
HSD  symbology  to  be  utilized  during  the  flight  scenarios.  The  required  hard¬ 
ware  facilities  for  ODS  testing  are:  the  CCS  computers,  the  MIDER  and  display 
simulators,  and,  for  System  Integration  Testing,  the  complete  AIDS  hardware 
suite. 

4.3  ACCEPTANCE  TEST  REQUIREMENTS 

The  acceptance  test  requirements  are  TBD. 
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APPENDIX  A 
GLOSSARY 

Ai rcraft 

AIDS  Command  Formatter 

Air  Control  Officer 

AIDS  Command  Language 

AIDS  Display  Formatter 

AIDS  Direction  Finder 

Auxiliary  Display  Unit 

AIDS  Equipment  Display  Description  Language 

AIDS  Equipment  Formatter 

Airborne  Early  Warning 

Advanced  Integrated  Display  System 

Antisubmarine  Warfare 

Barometric 

Bus  Controller 

Briefing  Information  Entry  Device 

Built-In  Test 

Built-In  Test  Equipment 

Central  Computer  System 

Computer  Control  Unit 

Configuration  Item 

Combat  Information  Control  Officer 

Compiler  Monitor  System 

Communications 

Data  Processor  ICS 

Extended  Arithmetic  Unit 
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FASP 

GLOSSARY  (Continued) 

Facility  for  Automated  Software  Production 

FLIR 

Forward-Looking  Infrared 

GRADS 

Graphic  Real-Time  Application  Display  Support 

HOS 

Helmet  Display  System 

HMD 

Helmet  Mounted  Display 

HOL 

High  Order  Language 

HOTAS 

Hands-on-Throttle- and-stick 

HPS 

Helmet  Position  Sensor 

HUD 

Head-Up  Display 

IAS 

Indicated  Airspeed 

Ibus 

Internal  Bus 

ICP 

Integrated  Control  Panel 

ICS 

Integrated  Control  Set 

IDS 

Interface  Design  Specification 

lEIS 

Integrated  Engine  Instrument  System 

IFF 

Identification  Friend  or  Foe 

ILS 

Instrument  Landing  System 

I/O 

Input/Output 

JTIDS 

Joint  Tactical  Information  Distribution  System 

LLLTV 

Low  Light  Level  Television 

LSAO 

Left  Status  Advisory  Display 

Mbus 

MIDER  Bus 

MCP 

Mode  Control  Panel 

MIDER 

Modular  Integrated  Display  Electronics  Rack 

MFD 

Multifunction  Display 
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GLOSSARY  (Continued) 


MPICS 

MRS 

NAV 

NAVAIRDEVCEN 

NAVAIRINST 

NORO 

NM 

NTDS 

OOS 

OSS 

FDD 

PDS 

PPS 

QA 

RPM 

RSAD 

RSG 

RT 

SAD 

SADI 

SECNAVINST 

SEMSO 

SOM 

SOSTEL 

STO 


Microprocessor  ICS 
Mission  Preparation  System 
Navigation 

Naval  Air  Development  Center 
NAVAIR  Instruction 
Non>0estruct1ve  Read-Out 
Nautical  Mile 
Naval  Tactical  Data  System 
Operational  Display  Software 
Operational  Support  Software 
Program  Design  Document 
Program  Design  Specification 
Program  Performance  Specification 
Quality  Assurance 
Revolutions  per  Minute 
Right  Status  Advisory  Display 
Raster  Symbol  Generator 
Remote  Terminal 
Status  Advisory  Display 
Standard  AIDS  Display  Interface 
Secretary  of  the  Navy  Instruction 
Sensor  Operator 
System  Operator's  Manual 
Solid  State  Electrical  System 
Short  Takeoff 
Short  Takeoff  and  Landing 
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GLOSSARY  (Continued) 

TACAN 

Tactical  Air  Navigation 

TACCO 

Tactical  Coordinator 

TBD 

To  Be  Determined 

TO 

Tactical  Display 

TIES 

Tactical  Information  Exchange  System 

TOR 

Tactical  Operational  Requirements 

TP 

Test  Plan 

TP/R 

Test  Procedures  and  Reports 

TP/S 

Test  Plans  and  Specification 

TR 

Test  Results 

TS 

Test  Specification 

UHF 

Ultra  High  Frequency 

:) 

ULAIDS 

Universal  Locator-Airborne  Integrated  Data  System 

Vbus 

Video  Bus 

1 

VHP 

Very  High  Frequency 
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VSD 

Vertical  Situation  Display 

V/STOL 

Vertical /Short  Takeoff  and  Landing 
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External  Bus 
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